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

[Mark Levedahl <mlevedahl@gmail.com>]

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.

>>> 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