On Thu, Apr 03, 2025 at 10:21:57PM -0700, Martin von Zweigbergk wrote:
> 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.
That sounds like sensible behaviour to me. We already know to print
ambiguous hashes, so we could probably do the same with change IDs:
$ git rev-parse 1234
error: short object ID 1234 is ambiguous
hint: The candidates are:
hint: 1234d8d9179 commit 2018-06-08 - Merge 'add-p-many-files'
hint: 1234e8297f3 commit 2020-10-26 - Merge branch 'en/sequencer-rollback-lock-cleanup' into next
hint: 123456ff3f0 tree
hint: 12349764e65 tree
hint: 1234b76f424 tree
hint: 1234c687269 tree
hint: 1234ebb5d8f blob
fatal: ambiguous argument '1234': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
1234
It should be rather easy to adapt this mechanism to also handle the case
where the same change IDs (or abbreviated change IDs) exist across
multiple commits.
Patrick
