Hello Peter, Am 25.06.2023 um 18:00 schrieb peter@easthope.ca:

From: Michael Schierl <schierlm@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