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

[Martin von Zweigbergk <martinvonz@google.com>]

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. We may change that to be an error instead [1].
The user can always fall back to using the commit id in such cases. We
call change ids with multiple visible commits "divergent". They
currently show up in red in `jj log`, which I think we all agree makes
them seem unnecessarily scary. We'll probably change that soon [2]
[3].

So when I said that I think it's quite uncommon to have multiple
commits with the same change id, I didn't mean that as an excuse to
not consider the other cases at all. I just mean that I think the vast
majority of commits are not cherry-picked, so we don't need to
optimize the user experience for that case - it's fine if it's a bit
more complicated to refer to such commits.

I hope that clarifies. Let me know if there are still unanswered
questions that I have missed.

[1] https://github.com/jj-vcs/jj/issues/5632
[2] https://github.com/jj-vcs/jj/pull/5800
[3] https://github.com/jj-vcs/jj/pull/5850