Subject: Re: Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer)

From: "Remo Senekowitsch" <[email-masked]>
Date: Wed, 23 Apr 2025 01:47:29 +0200

On Wed Apr 23, 2025 at 12:51 AM CEST, Nico Williams wrote:
>
> Using ticket IDs as change IDs implies a globally unique ID assigner,
> and should work well enough where things like bugzilla are used.

This email thread contains recurring ideas of stuffing unrelated
metadata into the change-id header (patch-id, ticket-id). I think we
should be careful not to do that.

The purpose of the proposed change-id is to identify and track how a
change evolves over time. We have talked about how those semantics may
or may not be clear enough, and that's a good thing to discuss.

It's also a good thing to discuss potential alternatives. E.g. "If we
have a patch-id, we don't need a change-id." I don't agree with that,
but it's a good thing to discuss.

But _deriving a change-id from_ a patch-id or ticket-id or whatever
completely destroys its purpose of tracking how a change evolves over
time. The change-id can only do that job if it _doesn't_ have other
unrelated semantics attached to it.

A patch can contain multiple changes. A ticket can be associated with
multiple changes. Deriving a change-id from either of them makes it
impossible to identify and track a single change.

So let's avoid mixing these concepts and talk about them as distinct
alternatives.