On Thu, Mar 23, 2023 at 10:38 PM Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > > On Mon, Mar 20, 2023 at 12:11 PM Andy Shevchenko > <andy.shevchenko@xxxxxxxxx> wrote: > > On Mon, Mar 20, 2023 at 7:02 PM Jeff King <peff@xxxxxxxx> wrote: > > > > Adding its author to the cc, who may be able to say more. But my > > > understanding is that this was probably fixing a bug (though I don't > > > know all the implications of having a branch checked out in multiple > > > worktrees). > > > > Note, in my case it's "checked" in the BARE repository, which means > > it's actually not. > > This case shouldn't be an impediment or racy AFAIU. > > In that case I agree it should work, but when I tried to reproduce the > issue the bare repository is ignored, only worktrees are considered. > > Are you sure the branch isn't checked out in other worktree(s)? Yes. Since the commit was in v2.26 already, and I have noticed the issue only recently, there are a few possibilities: 1) Debian is to slow to update a Git (doesn't sound like the case); 2) New version of the Git does something in the configuration files that unveils the issue; 3) Something else I've been missing? As for 2) I have found a new config.worktree which I tried to remove, nothing changed. Also I disabled extended worktree configuration in the main (~/.gitconfig) one. Didn't help either. I have a bare repo with a Linux kernel and two worktrees. The HEAD in the bare points out to one of the branches which I try to rebase. BARE:xxx (as shown by Git prompt helper in the Bash) `git rebase -X ours --onto "vN+1" "vN" xxx` fails. -- With Best Regards, Andy Shevchenko
