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

From: Patrick Steinhardt <[email-masked]>
Date: Thu, 3 Apr 2025 13:06:13 +0200

On Thu, Apr 03, 2025 at 12:38:52PM +0200, Remo Senekowitsch wrote:
> On Thu Apr 3, 2025 at 11:09 AM CEST, Patrick Steinhardt wrote:
> > On Wed, Apr 02, 2025 at 11:48:01AM -0700, Martin von Zweigbergk wrote:
> > The biggest question is of course backwards compatibility -- can we
> > introduce a change ID into the commit metadata without breaking existing
> > users? I guess you'll already have a lot of experience with this given
> > that you essentially already inject change IDs into metadata, and tools
> > generally handle this just fine?
> 
> Jujutsu has been injecting a 'jj:trees' header into commits to track
> more metadata around merge conflicts. There weren't any problems with
> that, unless one uses git to rewrite these commits with e.g. git-rebase,
> in which case that header is simply lost. But commits with conflicts are
> usually not pushed to a remote anyway, so the risk there was minimal.
> Scott Chacon with GitButler has more experience in this regard, since
> they actually push commits with a change-id in its header to remotes.
> He told the Jujutsu community that they didn't encounter any problems,
> no misbehaving tools that are fussy about unknown headers. The only
> problem is unknown commit headers being dropped by Git itself, depending
> on how it is invoked by the remote. (GitHub seems to preserve the header
> during a rebase-merge, because they use git-replay. GitLab and Forgejo
> drop the header.) With these insights from Scott, Jujutsu is moving
> forward to put the change-id in the commit header.

Yeah, Scott made me aware of the limitations in GitLab already. We
wanted to migrate to git-replay(1) for a long time already, but never
got around to actually doing this. Coincidentally I have recently been
talking with Chris, who proposed to finally go through with this change.
I guess this here is another factor that will make us schedule this
change sooner rather than later.

So: we'll soon start working on it, but I won't promise any timeline.

Patrick