CODEWITHSUNDEEP
gitversion-controlworking-directorygit-worktree
Yazeed Sabri
Yazeed Sabri

Reputation: 355

Inconsistency between working directory and working tree

I have been reading the git documentation for a while now and came to realize that in a lot of commands the documentation is ambiguous when it comes to the difference between "working directory" and "working tree". I'm aware of the changes to status here and more frequently used commands like add are consistent as well. But a grep on the documentation to a pull I did yesterday, shows that a lot of commands are still not updated accordingly.

This brings me to my next point, so what is the precise definition of each concept since they seem to be used interchangeably in config and stash documentation? Is working directory just an outdated mistake that is waiting to be fixed?

Was the change in status above made to solve the confusion and denote that status is unique per-working tree given its HEAD?

If this is the case, then is gc unique per-working tree too, or is it done on the "database" like fsck? Same idea with stash, does stash care on what working tree it was called?

Upvotes: 0

Views: 150

Answers (1)

torek
torek

Reputation: 487883

In version control systems in general (not just Git), one always has to have a place to work. The name used for this place varies: work tree, working tree, work directory, etc. Overall, work-tree or working-tree or some variant is probably best since "work directory" seems to imply a single level of "directory-ness".

Git's names have always been a bit inconsistent, but the move to use "work tree" or "working tree" has been fairly steady. Historically, this got more important when the git worktree sub-command went into Git officially, in Git version 2.5.

So, specifically:

Is [the phrase] working directory [in the git stash documentation] just an outdated mistake that is waiting to be fixed?

I would say so, yes.

Was the change in status above made to solve the confusion and denote that status is unique per-working tree given its HEAD?

Yes. Note, however, that git status computes the status dynamically, based on three items: HEAD (there is one HEAD per work-tree), the index (there is one index per work-tree), and the work-tree.

(Confusingly, any command can establish its own temporary index and use that. The one index per work-tree is the one "real" index for that work-tree, aside from any temporary index created temporarily by some command and set into $GIT_INDEX_FILE.)

If this is the case, then is gc unique per-working tree too, or is it done on the "database" like fsck?

git gc works on the database. However, because it removes unreferenced objects, it's a particularly complicated case: it must look at every index and every (possibly detached) HEAD, which means it must iterate over all work-trees.

Same idea with stash, does stash care on what working tree it was called?

What git stash does is to make two, or sometimes three, commits. It makes them from the index and from the work-tree, so it does matter which work-tree you are in. (The third commit, if present, holds untracked files: either untracked but not ignored, or untracked-including-ignored. These, too, come from the current work-tree.)

The commits themselves go on no branch. Instead, by default, one of the commits (the one that locates the others) is stored in refs/stash, using its reflog to retain any previous refs/stash value.

Upvotes: 2

Related Questions