From: Mark Levedahl <mlevedahl@gmail.com>
Date: Fri, 01 May 2026 16:42:39 GMT
Subject: Re: [PATCH v3 1/1] git-gui: handle missing worktree and separated gitdir
Message-ID: <a1a7237c-ffed-4a7a-ae58-55769aaa4453@gmail.com>
In-Reply-To: <77219c75-7968-413f-a642-0446145c8023@kdbg.org>

On 5/1/26 9:13 AM, Johannes Sixt wrote:
> Am 30.04.26 um 18:18 schrieb Mark Levedahl:
>>
>> On 4/30/26 6:02 AM, Shroom Moo wrote:
>> We have quite a bit of code that attempts to make Git GUI work from the
> .git directory and also in bare repositories.
>
> 87cd09f43e56 ("git-gui: work from the .git dir", 2010-01-23) made the
> first step. The original code just used the $_gitdir as the working
> directory. However, at that time we did not have alternate worktrees,
> and the old code, when used today, does not work in a `git
> worktree`-created worktree. Later, the `git rev-parse --show-toplevel`
> call came with 38ec8d3e2652 ("git-gui: correct assignment of work-tree",
> 2010-10-20). However, it also changes the fall-back code slightly, so
> that running Git GUI from the .git directory would not work the same way
> as before and takes the .git directory as the work tree (because in the
> .git directory --show-cdup is not "..", but empty).
>
> I think we need to restructure the existing flow a bit and not just fix
> a single spot in the code. I suggest this order of operation:
>
> 1. Handle the bare repository case. If not enabled, fail. Otherwise, we
> can work with an empty $_gitworktree.
>
> 2. Collect --show-toplevel into $_gitworktree.
>
> 2a. If this failed: If --is-inside-git-dir is true, and the last
> $_gitdir directory component is exactly ".git", take the parent
> repository as $_gitworktree. Otherwise, fail.
>
> 3. Handle all the other edge cases, if any, with the so determined
> $_gitworktree. (I didn't think through, yet, what needs to be done.)
>
> -- Hannes
>

I found one horrid edge case: 

Start git-gui in a gitdir not embedded in a worktree, with core.bare=false as there are
one or more gitfile and/or symlinked worktrees elsewhere.
- current git-gui aborts with an uncaught error. Good.
- git-gui with the wrapped --show-toplevel call finds no worktree to switch to, so runs in
the gitdir allowing commits of the gitdir items.
-  I just added and  committed the *file* refs/heads/master to branch master in such a gitdir.

git-gui's normal gui must be started ONLY if rev-parse --is-inside-work-tree is true. (The
blame view invoked by gitk in theory could be allowed to run in a bare repository
read-only mode.).

For read/write mode:
if --is-inside-git-dir == true at startup, we must abort, or find a valid worktree and
switch to that.

My personal preference is for git-gui to abort:
   I started git-gui where it cannot run. 
   My error. Let me learn and fix that.

Alternatively, ask me what to do:
    e.g., prepare a dialog after looking at git-worktree list, and the parent dir IFF this
dir is named .git, telling me of my mistake and offering me one or more worktrees to
switch to.

But please, don't just switch to another directory without asking. This is just
encouraging me to make careless errors.

Mark