From: Shroom Moo <egg_mushroomcow@foxmail.com>
Date: Fri, 01 May 2026 10:22:31 GMT
Subject: Re: [PATCH v3 1/1] git-gui: handle missing worktree and separated
Message-ID: <tencent_CCA549318D2A7DC6095954F2858371AB6D0A@qq.com>
In-Reply-To: <3b0b37ed-1a5d-4fe1-b2b4-7db67a62a06d@gmail.com>

Hi Mark,

Thanks for catching the multi‑worktree ambiguity. The parent‑directory
fallback can surely accidentally pick the wrong worktree. As a 
reminder, the current code deliberately supports starting git-gui from 
within a regular repository's .git directory.

The comment says:
# beware that from the .git dir this sets _gitdir to .
# and _prefix to the empty string

In that case, _gitdir is ".", _prefix is empty, and the later logic
falls back to using [file dirname $_gitdir] as the worktree. A blanket
"if --is-inside-git-dir then exit" would make that case useless.

I'll send a v4 that first checks --is-bare-repository (preserving the
original bare‑repo error), then checks --is-inside-git-dir and refuses
if inside a gitdir. This accepts the .git‑startup limitation in
exchange for safety, and keeps the bare‑repo message unchanged.

Two alternatives still exist if a different trade‑off is preferred: 
- Only check --is-inside-git-dir (simpler, but makes the
bare‑repo error_popup useless).
- After --is-inside-git-dir, consult git worktree list and
switch to the single worktree if unambiguous (keeps .git‑startup
but adds complexity and a runtime dependency).

Shroom