From: Johannes Sixt <j6t@kdbg.org>
Date: Wed, 06 May 2026 12:57:15 GMT
Subject: Re: [PATCH v3 1/1] git-gui: handle missing worktree and separated gitdir
Message-ID: <9fecbb11-3cc5-4084-bc29-bd948962dca0@kdbg.org>
In-Reply-To: <f6c7c3d5-1d68-45b5-87a7-ae19b59270f4@gmail.com>

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.

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

How does this scheme work when the user starts `git gui blame` in a bare
repository that does not have a worktree? Would this not produce an
error because no worktree was found?

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

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

-- Hannes