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

From: Toon Claes <toon@iotcl.com>
Date: Jun 6, 2025, 12:28 UTC
Message-ID: <87tt4t12c0.fsf@iotcl.com>
In-Reply-To: <aCJwgWaNoBVjvImJ@tapette.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 13 quoted lines

> On 2025-05-12 at 21:43:46, Martin von Zweigbergk wrote:
>> Random bytes has worked well for jj.
>
> I would like to suggest that we use a deterministic approach.  People
> rely on Git commits being deterministic, including in my stash
> import/export series[0].  In addition, it's important to avoid any
> allegations of side channels or leaking information in commits, which
> would be a concern in many environments and which a deterministic
> approach would avoid[1].
>
> I'd suggest a simple SHA-256 hash of the original commit data (for both
> SHA-1 and SHA-256 commits, but one that would change to a new hash if we
> added one) or an HMAC-SHA-256 with a fixed and documented key.

I was thinking: you cannot guarantee determinism, because the change-ID would remain stable, even when if the underlaying data on which it was generated changes. But on second thought, _some_ determinisn *can* be useful, for example when different tools try to generate a change-ID for the same source commit.

> I would also recommend a config option to avoid creating these IDs for
> those who don't want them included for privacy reasons.  I expect to set
> such an option, for instance.

Fair enough.

-- 
Cheers,
Toon