On Thu, 3 Apr 2025 at 22:00, Elijah Newren <newren@xxxxxxxxx> wrote: > > On Thu, Apr 3, 2025 at 8:47 PM Martin von Zweigbergk > <martinvonz@xxxxxxxxxx> wrote: > > > > On Thu, 3 Apr 2025 at 19:40, Elijah Newren <newren@xxxxxxxxx> wrote: > > > > > > One possible simple solution here is just to treat change-ids (or > > > there abbreviations) kind of like abbreviated hashes -- they aren't > > > guaranteed to be unique. If the user specifies a change-id and there > > > are multiple branches with such a change-id, we provide the user an > > > error much like we do for abbreviated hashes. > > > > > > Is that what folks have in mind? If so, I'll be happy to drop my > > > reservations about this aspect. > > > > Yes, that's close to what we have in mind. I think I just didn't > > explain clearly that it's mostly harmless in at least Jujutsu if there > > are multiple commits with the same change id. If there are multiple > > visible commits with the same change id, then you'll just have to > > decide what should happen when the user tries to refer to commits by > > change id. We currently let it resolve to all the visible commits with > > the given change id. > > resolve to all visible commits? So the Jujutsu equivalent of 'git > switch <change-id>' would simultaneously check out N different > branches? Or do commands which cannot accept multiple commits just > throw an error in such a case? Yes, the latter. The closest equivalent of `git switch` is `jj new` and that command actually does support multiple commits - that's how you create a merge commit. But we also have a little safeguard in the form of requiring you to say `jj new all:xyz` if you really want that. For commands where it's more expected and harmless to take multiple commits as input, we don't require the `all:` prefix. > Doing a "git log --no-walk <change-id>" and have it resolve to several > commits would be kinda cool... Yes, this is one of those commands where it's harmless so `jj log -r xyz` simply shows all (visible) commits with the given change id. Other examples include `jj abandon`, `jj describe`, `jj diff -r`, `jj rebase -r`, `jj squash --from`, while e.g. `jj rebase -d` (the destination) requires the `all:` prefix to allow multiple parents (making the roots of the rebased set into merge commits). > Yep, thanks, that answered all my previous questions...though you > raised one new one that I mentioned above. Yay!
