John Keeping <j...@keeping.me.uk> writes:
> If you set GIT_WORK_TREE you're telling Git to override all of the
> normal detection logic.
I didn't carefully read the other parts of the discussion, but this
is not entirely correct.
The actual/intended rules are fairly simple.
* With GIT_DIR (without GIT_WORK_TREE), you specify where the .git
directory is, and refuse the "normal detection logic". As you
refuse the normal "where is the root of the working tree and its
.git directory?" logic, Git uses the current directory as the
root of the working tree.
* But that means if you set GIT_DIR, you cannot work from a
subdirectory of your working tree--you always have to run Git
from the root level of your working tree. This may be
inconvenient.
* That is why GIT_WORK_TREE exists. It allows you to say "No, I am
not at the root level but am in a subdirectory somewhere inside
the working tree. The root level of the working tree is there
above, not here".
So it is a misconfiguration if you only set GIT_WORK_TREE without
setting GIT_DIR.
Also, if you set both and run Git from outside $GIT_WORK_TREE, even
though Git may try to do its best to give you a reasonable behaviour
[*1*], it is working by accident not by design (see the statement
you are making by setting GIT_WORK_TREE in the third bullet above).
IOW, running from outside GIT_WORK_TREE is a misconfiguration.
[Footnote]
*1* Think what should happen when you are outside GIT_WORK_TREE and
say this:
$ git grep foo
As you are not even inside the working tree, the command would
not know in which subdirectory you want to find the string foo;
the "reasonable behaviour" is to work on the whole working tree
in this case.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
