Hi, On Mon, 29 Jan 2018, Johannes Schindelin wrote: > On Fri, 19 Jan 2018, Jacob Keller wrote: > > > On Fri, Jan 19, 2018 at 10:55 AM, Phillip Wood > > <phillip.wood@xxxxxxxxxxxx> wrote: > > > On 19/01/18 12:24, Phillip Wood wrote: > > >> > > >> On 18/01/18 15:35, Johannes Schindelin wrote: > > >>> > > >>> Internally, the `label <name>` command creates the ref > > >>> `refs/rewritten/<name>`. This makes it possible to work with the labeled > > >>> revisions interactively, or in a scripted fashion (e.g. via the todo > > >>> list command `exec`). > > >> > > >> If a user has two work trees and runs a rebase in each with the same > > >> label name, they'll clobber each other. I'd suggest storing them under > > >> refs/rewritten/<branch-name or detached HEAD SHA> instead. If the user > > >> tries to rebase a second worktree with the same detached HEAD as an > > >> existing rebase then refuse to start. > > >> > > > > > > Ah this isn't a concern after all as patch 5 makes refs/rewritten local > > > to the worktree. Perhaps you could move that part of patch 5 here or add > > > a note to the commit message that it will become worktree local later in > > > the series > > > > > > Best Wishes > > > > > > Phillip > > > > I'd rather it be included here as well. > > But it would have been really easy to overlook in here. I really want this > to be a separate commit, also to have a chance to get this done > *differently* if somebody comes up with a splendid idea how to do that > (because hard-coding feels quite dirty). BTW there is an additional good reason why the patch to make refs/rewritten/* worktree-local is so far away: that is the first time in the patch series when we can test this really effectively; at that stage we can easily just add to t3430 because all the building blocks for `rebase -i --recreate-merges` are in place. Ciao, Dscho
