[Oberon] Re (2): Git usage for A2.

[Michael Schierl]

Hello Peter,


Am 25.06.2023 um 18:00 schrieb peter at easthope.ca:
> From:	Michael Schierl <schierlm at gmail.com>

> Now you might think "Why did I respond to Peter's first question?"

I don't get this. I respond to a question when I think I can answer it,
not related whether it is their "first" or not "first" question.

> Git doesn't give a name to the "empty directory" does it?  "Repository
> container directory"?.

I assume you mean after the empty directory has been filled with both
the work tree and the local repository?

Some people just call it a "git clone" like the command that created it.
But it is misleading when you did not create it by the clone command.
And to be honest I never had a need to refer to it specifically.

>> git checkout -b somebranch --track bar/somebranch
>> git branch -D main
>
> What about bar?
> git checkout -b somebranch --track bar/somebranch

When you want to work on a branch, you have to decide which repository
it should come from. In that case, you create a branch called
"somebranch" which tracks the branch "somebranch" of your "bar" remote
repository.

"tracking" means that if you fetch, pull or push while you have this
branch active (checked out into your work tree) and do not specify a
remote branch, that remote branch will be used.

> HYPOTHESIS: a file in the local repository is never edited directly.
> A file in the work tree can be edited directly.

Very rarely at least. There are a few workflows where you may want to
edit files in the repository directly (ones in the repository root, not
some of the ones with hash names), but there should always be a way to
avoid it if you feel uneasy.

>> For completeness, "add" will move changes from your working tree to
>> your staging area,
>
> Staging area?  Not mentioned elsewhere.  What, where is staging area?

Surely mentioned at lots of places :-) If you don't trust Google, the
Git Book <https://git-scm.com/book/en/v2> got you covered in
<https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository>

The staging area is part of your local repository where you can select
what you want to commit in your next change. While you do not need to
use the staging area, maybe it is helpful to know that it exists.

Assume you are working on a new feature where you added X.Mod, heavily
modified Y.Mod and added 2 lines to Z.Mod. While at another place of
Z.Mod, you had to add 3 more lines which are not part of the feature,
but need to be there while you test the new feature (either because they
work around a bug you have not found time to track down or because they
are part of another feature that modifies some other files).

When you now want to push the changes relevant to that feature to a
remote repository (to discuss them, or to submit them for inclusion
upstream), you don't want to include those 3 lines in Z.Mod, yet maybe
you don't want to delete them or you might forget adding them later.

Subversion provided a "restore after commit" feature for that workflow,
i.e. you mark your file "restore after commit", delete those 3 lines,
commit the rest and the 3 lines magically appear again. Yet still, when
you get interrupted before you finish your commit, those 3 lines are not
in the file and you may wonder why something else does not work.

Git solves this using the staging area. Some commands (e.g. "git add -p"
or git gui) provide the way to choose the lines you want to stage. So on
disk, Z.Mod is still with all 5 lines changed, yet when you do your
commit (later), Z.Mod will only add 2 of them. "git diff" will show the
3 unstaged different lines and "git diff --staged" will show the 2
staged different lines). "git status" will show that the file is
partially staged.

When doing a commit, you have to decide whether you want to commit from
the staging area (if you give no flags) or from the work tree (if you
give the "-a" flag).

So in your example using the staging area you would do

git add -p Z.Mod # -- select which lines you want to add --
git add X.Mod Y.Mod # add changes in whole files to staging area
git diff --staged # to see what you will commit
git commit


Without using the staging area, you would do:

git add -N X.Mod  # to add a new file without staging it
cp Z.Mod Z.Mod.tmp
# -- edit Z.Mod to remove the extra lines
git diff # to see what you will commit
git commit -a
mv Z.Mod.tmp Z.Mod


Regards,


Michael