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
