Subject: Re: [PATCH] Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"

From: Junio C Hamano <[email-masked]>
Date: Tue, 22 Dec 2015 13:50:12 -0800

Duy Nguyen <[email-masked]> writes:

> On Tue, Dec 22, 2015 at 1:31 AM, Junio C Hamano <[email-masked]> wrote:
>> Junio C Hamano <[email-masked]> writes:
>>
>>> Nguyễn Thái Ngọc Duy  <[email-masked]> writes:
>>>
>>>> This commit has caused three regression reports so far. All of them are
>>>> about spawning git subprocesses, where the new presence of GIT_WORK_TREE
>>>> either changes command behaviour (git-init or git-clone), or how
>>>> repo/worktree is detected (from aliases), with or without $GIT_DIR.
>>>> The original bug will be re-fixed another way.
>>>>
>>>> Signed-off-by: Nguyễn Thái Ngọc Duy <[email-masked]>
>>>> ---
>>>>  On Thu, Dec 3, 2015 at 12:09 AM, Junio C Hamano <[email-masked]> wrote:
>>>>  > OK, when/if you decide that our first step should be a revert of
>>>>  > d95138e please send in a patch to do so with a brief write-up of a
>>>>  > follow-up plan.
>>>>
>>>>  Three reports to me are enough. And I obviously could not push the
>>>>  fix out fast enough. So if you want to revert it, here's the patch on
>>>>  maint.
>>
>> Also, can you reference these three reports for future reference?
>
> http://article.gmane.org/gmane.comp.version-control.git/281608
> http://article.gmane.org/gmane.comp.version-control.git/281979
> http://article.gmane.org/gmane.comp.version-control.git/282691
>
> The last one is not confirmed by the reporter yet. But I'm pretty sure
> i'll trigger the special case "when GIT_WORK_TREE is set but GIT_DIR
> is not" in setup code

Thanks, I'll leave these breadcrumbs in the log message for future
reference.

I think the last sentence of the original commit is telling how this
bug came about.  "It does not harm if $GIT_WORK_TREE is set while
$GIT_DIR is not." forgets to consider the possibility that scripts
may be relying on the "Go to the top of the working tree and setting
GIT_DIR would give you a reasonable environment".  That is true if
GIT_WORK_TREE is not set, and these scripts weren't getting the
environment exported [*1*].  These scripts now have to unset
GIT_WORK_TREE themselves (or set it to their $cwd if they are indeed
at the top), just in case the process that calls them exports it
X-<.

Thanks.

[Footnote]

*1* If the end user has GIT_WORK_TREE in the environment, even if
    Git stops exporting it by reverting d95138e, such a script may
    break.  So in that sense, d95138e did not quite change the rule
    of the game for these scripts, but made it more obvious when
    these scripts were written sloppily.