[AceJohnny2]

This is exciting, convergence is always good, but I'm confused about the value of putting the tracking information in a git commit header as opposed to a git trailer [1] where it currently lives.

In both cases, it's just metadata that tooling can extract.

Edit: then again, I've dealt with user error with the fragile semantics of trailers, so perhaps a header is just more robust?

[1] https://git-scm.com/docs/git-interpret-trailers

[aseipp]

Mostly because it is jarring for users that want to interact with tools which require these footers -- and the setups to apply them, like Gerrit's change-id script -- are often annoying, for example supporting Windows users but without needing stuff like bash. Now, I wrote the prototype integration between Gerrit and Jujutsu (which is not mainline, but people use it) and it applies Change-Id trailers automatically to your commit messages, for any commits you send out. It's not the worst thing in the world and it is a little fiddly bit of code.

But ignore all that: the actual _outcome_ we want is that it is just really nice to run 'jj gerrit send' and not think about anything else, and that you can pull changes back in (TBD) just as easily. I was not ever going to be happy with some solution that was like, "Do some weird git push to a special remote after you fix up all your commits or add some script to do it." That's what people do now, and it's not good enough. People hate that shit and rail at you about it. They will make a million reasons up why they hate it; it doesn't matter though. It should work out of the box and do what you expect. The current design does that now, and moving to use change-id headers will make that functionality more seamless for our users, easier to implement for us, and hopefully it will be useful to others, as well.

In the grand scheme it's a small detail, I guess. But small details matter to us.

[AceJohnny2]

Thanks for the explanation!

While you're around, do you know why Jujutsu created its own change-id format (the reverse hex), rather than use hashes (like Git & Gerrit)?

[aseipp]

I don't know if it's the only or original reason, but one nice consequence of the reverse hex choice is that it means change IDs and commit IDs have completely different alphabets ('0-9a-f' versus 'z-k'), so you can never have an ambiguous overlap between the two.

Jujutsu mostly doesn't care about the real "format" of a ChangeId, though. It's "really" just any arbitrary Vec<u8> and the backend itself has to define in some way and describe a little bit; the example backend has a 64-byte change ID, for example.[1] To the extent the reverse hex format matters it's mostly used in the template language for rendering things to the user. But you could also extend that with other render methods too.

[1] https://github.com/jj-vcs/jj/blob/5dc9da3c2b8f502b4f93ab336b...

[martinvonz]

Yes, it was to avoid ambiguity between the two kinds of IDs. See https://github.com/jj-vcs/jj/pull/1238 (see the individual commits).

[aseipp]

Interesting, that was just a few short months before I showed up. :)

[steveklabnik]

I'm not an expert on this corner of git, but a guess: trailer keys are not unique, that is

  Signed-off-by: Alice <[e-mail]>
  Signed-off-by: Bob <[e-mail]>

is totally fine, but

  Change-id: wwyzlyyp
  Change-id: sopnqzkx

is not.

I've also heard of issues with people copy/pasting commit messages and including bits of trailers they shouldn't have, I believe.

[bananapub]

~I think it's more that not all existing git commands (rebase, am, cherry-pick?) preserve all headers.~

ignore, misread the above

[steveklabnik]

That's a downside of using headers, not a reason for using them. If upstream git changes to help this, it would involve having those preserve the headers. (though cherry-pick has good arguments of preserving vs generating a new one)

[bananapub]

ah, I'm sorry, I misread your comment (and should have mentioned the cherry-pick thing anyway).

[steveklabnik]

It’s all good!