From: Johannes Sixt <j6t@kdbg.org>
Date: Sat, 23 May 2026 08:01:40 GMT
Subject: Re: [PATCH v2 07/11] git-gui: try harder to find worktree from gitdir
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:
> 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 {}
>> +		}
>> +	}

> 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