Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer

[Patrick Steinhardt <ps@pks.im>]

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@gmail.com> wrote:
> >
> > On Thu, Apr 3, 2025 at 8:47 PM Martin von Zweigbergk
> > <martinvonz@google.com> wrote:
> > >
> > > On Thu, 3 Apr 2025 at 19:40, Elijah Newren <newren@gmail.com> 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