JJ and GitButler already create and inject this into the commit headers (using the same interoperable reverse-hex format), which is recognized by Gerrit and some forges like Tangled for incremental commit based review.

I doubt that core Git will adopt it anytime soon as it was not discussed at this years contributor summit (last week) and doesn't seem to be a hot topic on the ML.

What I would like to see is support for `git rebase` not dropping it, which is the current main issue. The `git replay` command, as well as commands based on the same sequencing code (`git history` for example) do not drop custom headers like this, so there is partial non-breakage, but several of the other history editing commands do drop custom headers.

Having switched to jj I totally agree. Change IDs are a huge UX win.

Yeah, "standardizing" change IDs would make it much easier to develop further tooling around it. In particular decentralized review is something that I'd be interested in.

For example, if GitHub is down, that would not be a blocker to access review comments or to do reviews. And maybe you could push your reviews to a GitLab mirror if you want a UI.

How is this different from branches?

It's much, much worse than that.

Yes, you do need to do that. However, there is also much more work after that.

Git will not intermingle SHA-256 and SHA-1 enabled repositories, even in things like submodules, so anything used in that manner will need to keep both versions into the indefinite future. If you rely on a submodule that has not yet converted, you will have to convert it yourself and try to keep it up to date, or the forge will have to automatically keep a bidirectional mirror (if you have submodules in various forges, you'll have to wait for all of them to do it), etc.

This means that every SHA referenced anywhere on the internet, in commit messages, in issues, in code comments is now invalid and needs a mapping to find the rewritten one for forever.

It also means that every commit signature ever made is now invalid and will probably have to be stripped from the rewritten new 256 history because it's impossible to resign everything.

Companies like Google and GitHub are working on keeping two versions of each repository so that there can be long stages of ecosystem migrations, but no matter what, it's going to be a huge pain for millions of developers for years to come.

That's odd. Why not compute both sha1 and sha256 for all git objects for the foreseeable future?

Failing that, have a kind of git object that wraps another and says hey this is in sha1 don't mess with it

i guess that for now only the default will change for new repositories. support for sha1 is not going to be dropped, so most existing repositories won't switch any time soon. if you want to switch then yes, it sounds like a force push might be needed, although it could also be that simply switching is not possible, but that instead you have to create a new repo and import the history from the old repo, forcing everyone to clone the new repo intentionally.

It is a giant format change, but in the current documentation [0] sounds more like a repack than a force-push. git keeps a lookup table of the SHA1 object ids similar to an index file and some interop is allowed between SHA1 repositories and SHA256. (Primarily if you still needed to use GitHub as an SHA1 server because of some support hiccup, but needed your local repo to be SHA256 for security or other reasons, that's partially/mostly supposted.) Objects need to be resigned with their SHA256 id, but for different reasons than rebase/force-push and with a subtly different developer experience. In theory using that compatibility index of SHA1 hashes a good UI could show both signatures.

[0] Migration document: https://git-scm.com/docs/hash-function-transition

Couldn't you write something that checks every commit's content and message is byte equal to the old tree? One scan through the history to verify it should be relatively simple if not cheap. Should be built into git.