Re: [PATCH v3 1/1] git-gui: handle missing worktree and separated gitdir

[Mark Levedahl <mlevedahl@gmail.com>]

On 5/6/26 8:57 AM, Johannes Sixt wrote:
> Am 06.05.26 um 13:27 schrieb Mark Levedahl:
>> A git repository (gitdir) can have config.bare true | false | not set
>> git rev-parse --is-bare-repository tells you that whatever gitdir is discovered from the
>> current directory has core.bare==true. This happens whether the call is from inside the
>> gitdir, or in the parent dir of a gitdir named '.git', or in a directory containing a
>> symlink or a gitfile link to the gitdir. This call never tells you what directory you are
>> actually in.
> OK. But how does "find out which directory we are in" come into play
> here? If we find a bare repository, we do not need a worktree. If we are
> in a non-bare repository, we can find the worktree with `rev-parse
> --show-toplevel`.
>
>> git rev-parse --is-inside-work-tree gives:
>>     true - the call is made from a directory that is suported/supportable as a worktree of
>> a gitdir.
>>     false - the call is made from inside a gitdir, or from a directory linked to a to a
>> gitdir with core.bare == true.
>>     and error is thrown if no gitdir is discovered.
>>
>> I find --is-inside-work-tree a much better call to make early in setup. 
>>     true - full git-gui is ok, 
>>     false - blame/browser is ok (gitdir might have core.bare true)
>>     error - no gitdir found, the repository picker should be called.
> But we would still make an exception for the case that $PWD is a
> non-bare repository named ".git", because then, by Git GUI's definition,
> its parent is the corresponding worktree.

I find the organization using rev-parse --is-inside-work-tree easier to reason about, and
if I were writing this from scratch, I would do it that way. But, you have one or more
patches in progress, if this idea is useful there great, otherwise, drop it.

>> As you mentioned elsewhere, the problem on browser/blame is that _gitworktree is empty
>> when no worktree is found, so GIT_WORK_TREE is exported to the environment as an empty
>> variable. This cause is in a commit from 12 years ago:
>>
>>     3decb8e0ac ("git-gui: tolerate major version changes when comparing the git version",
>> 2014-05-17)
> I don't think that this commit very relevant. The problem is in `git
> branch --show-current` (and probably other git command variants) that
> want to turn an empty $GIT_WORK_TREE into an absolute path even in cases
> where no worktree is needed. I haven't tried to figure out which commit
> (in the Git repository) started to do this.

Reverting that commit in any way has nothing to do with fixing this problem now. But,
detecting breakage at that commit is what lead me to discover the problem was _gitworktree
== {} and GIT_WORK_TREE="". As you say, browser/blame may well not have broken until a
more recent commit to git itself. I cannot say, even the 2019 git prior to rev parse
--top-level being taught to error out will not build on my computer due to incompatibilities.

>> The fix is to set _gitworktree to _gitdir before exporting GIT_WORK_TREE, or to just not
>> export an empty GIT_WORK_TREE. Obviously, having GIT_WORK_TREE = GIT_DIR is asking for
>> trouble, but perhaps is ok as git-gui is running in a read-only mode for browse/blame. My
>> limited testing shows this works.
> Good to know. My preference is to not set GIT_WORK_TREE at all provided
> that setting GIT_DIR without GIT_WORK_TREE is a use-case supported by Git.
>
>

I just confirmed that git-gui modified to export GIT_DIR only, not GIT_WORK_TREE, and
actually to make sure GIT_WORK_TREE is not in env, has blame/browser working correctly in
a gitdir with no worktree.

Mark