What does this patch do when you do this?
: Because I usually work with this repository...
$ GIT_DIR=$some_repository
$ export GIT_DIR
: Then much later, I happen to visit another repository
: to take a peek...
$ cd $somewhere_else
$ git --git-dir .git some-command
I think --git-dir request on the command line is primarily to
allow overriding whatever the user has in the environment as the
fallback default, so if the patch makes it barf that is not very
nice.
Junio C Hamano [off-list ref] wrote:
What does this patch do when you do this?
: Because I usually work with this repository...
$ GIT_DIR=$some_repository
$ export GIT_DIR
: Then much later, I happen to visit another repository
: to take a peek...
$ cd $somewhere_else
$ git --git-dir .git some-command
This one has no alias involved as far as I see, so there is no change.
The patch makes git barf when an alias changes the environment (i.e.
an alias uses --git-dir/--work-tree/--bare). When git has read the
configuration file to find out about aliases setup_git_env has been
called and a pointer returned by getenv("GIT_DIR") is already stored
in a static pointer. If the environment variable is changed
afterwards git might or might not use the new value depending on the
implementation.
That is what my example shows: FreeBSD libc reuses the old memory
location if the new value of an environment variable fits in the old
place. Because setup_git_env uses xstrdup on the object dir and some
other directories the old value is used for those but the new one is
used for git_dir (which is just a pointer returned by getenv). This
way HEAD is read from the new repository but objects are searched in
the old repository.