From: Phillip Wood Date: Thu, 29 Oct 2026 16:10:03 GMT Subject: Re: [PATCH v2] worktree list: add --branch to select worktrees by branch Message-ID: In-Reply-To: On 29/10/2026 14:23, Ben Knoble wrote: > >> Le 29 oct. 2026 à 07:14, Phillip Wood a écrit : >> >> Hi Jasper >> >>> On 29/10/2026 04:46, Jasper Mayone wrote: >> >>> Is that change in behavior acceptable? A script that reads >>> %(worktreepath) would now get a path for a branch that is being >>> rebased. I think that is a fix, since the rest of Git already >>> considers that branch checked out, but I would like to hear if anyone >>> relies on the empty value. >> >> I think we can consider the change in behavior to be a bug fix. > > If we’re doing this in order to usefully feed it to worktree-remove, though, > do you really want to remove a worktree that is mid-rebase? I > would think that could have work you don’t want to throw away > without considering. (Besides which, would it show up > in --merged=origin? Hm.) > > I suppose I would expect remove to fail without a « force » flag if > the worktree is mid-rebase, but still. That's an interesting point. I agree "git worktree remove" shouldn't remove a worktree that's in the middle of a rebase or bisect. To me that is a bug in "git worktree remove" that is more likely to be triggered if we start reporting the worktree where branches are being rebased. Thanks Phillip