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

From: Mark Levedahl <mlevedahl@gmail.com>
Date: May 6, 2026, 11:27 UTC
Message-ID: <f6c7c3d5-1d68-45b5-87a7-ae19b59270f4@gmail.com>
In-Reply-To: <ac115a8f-5dbc-4988-b8a5-c1647af1bb74@kdbg.org>

On 5/6/26 3:32 AM, Johannes Sixt wrote:

>> Whether being in a gitdir is ok, or a worktree required, is of fundamental importance and
>> is not explicitly checked now. This is my issue. (Whether the repo is bare, or embedded in
>> a worktree, is relevant only when automatically fixing a user error.)
> I don't quite follow what you a trying to say here.

I played a bit more:

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.

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.

So, the only need to test if the repo is marked bare is when looking for a possible worktree when git-gui was started inside the gitdir, or started in a directory linked to said gitdir, or GIT_DIR in the environment points to said gitdir: I consider all of this a user (or configuration) error, and there are many possible causes to explore to give useful feedback to the user.

But, there are many ways to code this. I started down a path of using --is-inside-worktree, but in the end there are still a lot of corner cases to find.

Show 11 quoted lines

>>> But perhaps there is a simpler solution: Let's present an error if
>>> --show-toplevel fails except in the case where the startup directory is
>>> named '.git' (and is a valid Git repository) and is not bare (then the
>>> worktree is the parent). I insist in this exception, because this
>>> use-case was considered important in the past (87cd09f43e56 "git-gui:
>>> work from the .git dir", 2010-01-23).
>>>
>>> -- Hannes
>>>
>> This would not fix gitk's blame / browse from a gitdir, and I don't really see a one or
>> two line fix as being adequate.

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)

Prior to that commit and if not using git v1.7.x, an alternate branch of code not using git rev-parse was used for worktree discovery, and that code set _gitworktree = _gitdir when in a gitdir. The alternate code was removed more recently as it was unreachable from non-ancient git versions.

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.

Mark