Subject: Re: [PATCH v2 1/3] worktree: remove "the_repository" from is_current_worktree()

From: Shreyansh Paliwal <[email-masked]>
Date: Mon, 23 Mar 2026 22:35:32 +0530

> On 23/03/2026 09:41, Shreyansh Paliwal wrote:
> >
> > This may be slightly out of scope for this series. My understanding so far
> > has been that originally wt == NULL is used to represent the 'current worktree',
> > which eventually meant following the process-wide state (the_repository).
> > With the ongoing multi-repository work, the meaning is being changed to be
> > interpreted as 'the worktree associated with the repository that we are working in'.
> > However, in path.c there are some callers of repo_git_pathv() passing wt as 'NULL',
> > I know that there is not involvement of the_repository state but it would be create
> > less confusion if the semantics of worktrees are same everywhere. So if we replace
> > those NULL callers with the current worktree and update the checks of (!wt) to
> > (is_current_worktree(wt)), some tests are failing mostly related to refs of linked
> > worktrees, and I think the error is originating from this,
> >
> >          if (!wt)
> >                  adjust_git_path(repo, buf, gitdir_len);
> >
> > So I am a bit confused to whether wt being NULL here could mean something else
> > behaviour wise ?
>
> That line comes from 543107333b3 (path: worktree_git_path() should not
> use file relocation, 2017-06-22) which explains why we don't adjust the
> patch when wt is non-NULL. worktree_git_path() is called from
> builtin/fsck.c in a loop over all worktrees so changing 'if (!wt)' 'if
> (!wt->is_current)' will change the behavior for the current worktree.
> While it might be nice to clean this up in the future, it is an internal
> helper function so I'm less worried it than if it were a public function.

Hmm, I see. That would end up calling adjust_git_path() for the current worktree
in that list of worktrees, which wasn’t happening before, that makes sense.
Thanks.