From: Shroom Moo Date: Sat, 23 May 2026 11:47:44 GMT Subject: Re: [PATCH v2 07/11] git-gui: try harder to find worktree from gitdir Message-ID: In-Reply-To: On 5/23/26 4:01 PM, Johannes Sixt wrote: > 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 I see. The condition is unrelated to this patch. Users should handle this case as assigning manually by rule. Indeed we don't need to modify it. Shroom