Re: [PATCH v2 07/11] git-gui: try harder to find worktree from gitdir
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- May 23, 2026, 08:01 UTC
- Message-ID
- <c8d1ab1e-e0cb-44e2-afcd-728b7b43774c@kdbg.org>
- In-Reply-To
- <tencent_E13EB585242AD7C263B8B3B732A428465D09@qq.com>
Am 21.05.26 um 06:55 schrieb Shroom Moo:
Show 16 quoted lines
> On 5/21/26 4:24 AM, Mark Levedahl wrote:
>> + } elseif [file exists {gitdir}] {
>> + if {[catch {
>> + set fd_gitdir [open {gitdir} {r}]
>> + set gitlink_parent [file dirname [read $fd_gitdir]]
>> + catch {close $fd_gitdir}
>> + set worktree [git -C $gitlink_parent rev-parse --show-toplevel]
>> + set parent_gitdir [git -C $worktree rev-parse --absolute-git-dir]
>> + if {$::_gitdir ne $parent_gitdir} {
>> + set worktree {}
>> + }
>> + }]} {
>> + catch {close $fd_gitdir}
>> + set worktree {}
>> + }
>> + }Show 5 quoted lines
> Additionally, [file exists {gitdir}] checks for the gitdir file in
> the current working directory. Since the function has not yet
> switched to $_gitdir when this check runs, it is almost impossible
> to find the file. Consequently, this logic never triggers, preventing
> linked worktrees from being recognized. I think you are misunderstanding which use-case this code is addressing. The case can be triggered very easily.
First, the code before the part we see above is intended for the special case where we start in a .git, where `--show-toplevel` bails out and we define the worktree to be the directory containing .git.
However, if we start in .git/worktrees/feature, then the code cited above kicks in, because `--show-toplevel` still bails out, `--absolute-git-dir` does not end in '.git', but now we have a file named 'gitdir' in the current directory. In this case, we define (and this is new with this patch) that the worktree is the one where the 'gitdir' points.
-- Hannes