Re: [PATCH v2 01/11] git-gui: guard set/unset of GIT_DIR and GIT_WORK_TREE

[Mark Levedahl <mlevedahl@gmail.com>]

On 5/22/26 4:06 AM, Johannes Sixt wrote:
> Am 20.05.26 um 22:24 schrieb Mark Levedahl:
>> 2.54.0.215.g4fe990ec16
>>
>> ------ 8< ------
>> Subject: [PATCH 2/2] git-gui: operate git commands without GIT_WORK_TREE
>>
>> The manual page of the git command states about the --git-dir option:
>>
>>    Specifying the location of the ".git" directory using this option
>>    (or GIT_DIR environment variable) turns off the repository
>>    discovery [...], and tells Git that you are at the top level of
>>    the working tree.
>>
>> Use this to our advantage:
>>
>> - Set GIT_DIR in the environment to the value that was discovered, so
>>   that the invoked git commands operate on the same repository
>>   database that Git GUI uses even after it changes the working
>>   directory.
>>
>> - After changing the working directory to the top level of the working
>>   tree, ensure that GIT_WORK_TREE is not set, because, as per
>>   documentation, all git invocations from then on will assume that the
>>   current working directory is also the top level working tree.
>>
>> - Remove the now obsolete GIT_WORK_TREE dance when subordinate Gitk or
>>   Git GUI are invoked for a submodule.
>
> 2.54.0.215.g4fe990ec16
>
> ------ 8< ------
> Subject: [PATCH 2/2] git-gui: operate git commands without GIT_WORK_TREE
>
> The manual page of the git command states about the --git-dir option:
>
>    Specifying the location of the ".git" directory using this option
>    (or GIT_DIR environment variable) turns off the repository
>    discovery [...], and tells Git that you are at the top level of
>    the working tree.
>
> Use this to our advantage:
>
> - Set GIT_DIR in the environment to the value that was discovered, so
>   that the invoked git commands operate on the same repository
>   database that Git GUI uses even after it changes the working
>   directory.
>
> - After changing the working directory to the top level of the working
>   tree, ensure that GIT_WORK_TREE is not set, because, as per
>   documentation, all git invocations from then on will assume that the
>   current working directory is also the top level working tree.
>
> - Remove the now obsolete GIT_WORK_TREE dance when subordinate Gitk or
>   Git GUI are invoked for a submodule.
> 2.54.0.215.g4fe990ec16
>
> ------ 8< ------
> Subject: [PATCH 2/2] git-gui: operate git commands without GIT_WORK_TREE
>
> The manual page of the git command states about the --git-dir option:
>
>    Specifying the location of the ".git" directory using this option
>    (or GIT_DIR environment variable) turns off the repository
>    discovery [...], and tells Git that you are at the top level of
>    the working tree.
>
> Use this to our advantage:
>
> - Set GIT_DIR in the environment to the value that was discovered, so
>   that the invoked git commands operate on the same repository
>   database that Git GUI uses even after it changes the working
>   directory.
>
> - After changing the working directory to the top level of the working
>   tree, ensure that GIT_WORK_TREE is not set, because, as per
>   documentation, all git invocations from then on will assume that the
>   current working directory is also the top level working tree.
>
> - Remove the now obsolete GIT_WORK_TREE dance when subordinate Gitk or
>   Git GUI are invoked for a submodule.

The manual page is incomplete: if the repository has set core.worktree=/somehere, that is
the root of the worktree and the current directory is always ignored. git rev-parse will
report /somewhere as the answer to --show-toplevel regardless of current directory, even
if inside the gitdir, and even if GIT_DIR is used.

The user can override with GIT_WORK_TREE, and if so we must keep GIT_WORK_TREE in the
environment if it was set. So, an alternative for deciding when to export is

if core.worktree and GIT_WORK_TREE are both set AND GIT_WORK_TREE != core.worktree
    export GIT_WORK_TREE

If the user set GIT_WORK_TREE empty, git rev-parse will throw an error so we would never
to far enough to try to export that.

Mark