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

From: "Remo Senekowitsch" <[email-masked]>
Date: Fri, 04 Apr 2025 09:41:24 +0200

I'll try to join some of our threads and summarize... please correct me
if you disagree with that summary (or I've left something out you think
is important).

One of my points was that rebase usually doesn't lead to multiple
visible commits with the same change-id, whereas cherry-pick usually
does. You pointed out that rebase can in fact lead to multiple visible
commits with the same change-id and cherry-pick sometimes doesn't (and
some of these examples represent valid use cases). So making these two
commands behave in a different way that only makes sense in the "common"
case makes them more complicated - and less consistent - in the general
case. I find this convincing and I now agree that both cherry-pick and
rebase should preserve the change-id by default.

The Gerrit developers will be happy about this anyway, and it's worth
repeating that Jujutsu can deal with it perfectly fine while preserving
almost all benefits of change-ids.

When discussing the uniqueness of change-ids or lack thereof, I'd
like to introduce one more factor: At which point in time during the
development cycle a change-id is unique. Jujutsu users derive most
of the benefits of change-ids during active development. The use case
you find most important - tracking (forward- and) back-ports - happens
at a different time during development, when a change has been merged
to a public branch already. So I think there is no conflict at all.
Change-ids will naturally tend to be unique during active development
and once they are merged, whether the change-id stays unique or not
doesn't matter anymore for those active development use cases. We can
have our cake and eat it too.

Remo