This means, if you migrate your repo, every single commit message that contains text like: "please see commit <sha1>" will now be broken.

This will be a train wreck. I hope they don't release before adding compatibility modes to keep the existing sha1's around in the database.

▲

oasisaimlessly 9 hours ago | parent | next [-]

Tools like git-filter-repo[1] support rewriting commit hashes in commit messages. git-filter-repo actually does it by default; see `--preserve-commit-hashes` in the manual[2].

[1]: https://github.com/newren/git-filter-repo

[2]: https://htmlpreview.github.io/?https://github.com/newren/git...

▲

donatj 9 hours ago | parent | next [-]

Sure, but that's not going to rewrite Slack messages, emails, GitHub links, docs

▲

purpleidea 9 hours ago | parent | next [-]

Came to say something exactly like this... The old sha1 handle needs to be still available in the same way an HTTP 301 redirect would work.

▲

diegocg 9 hours ago | parent | prev [-]

... do not migrate old repos? I'm not sure why people would do that. Or, if they do, why would they replace the current repo name instead of creating a different one and keeping the old one closed to make the references work.

I don't think this is going to be a problem at all.

	▲	beart 6 hours ago \| parent [-]
		Hmm. If this is a security issue that matters, would you not be expected to migrate? Not talking about archived code, but active projects that pre-date git 3.0

▲

okanat 4 hours ago | parent | prev [-]

I need git-filter-repo to rewrite entire documentation and also resurrect and rehire earlier employees to repeat their GPG signatures.

▲

112233 9 hours ago | parent | prev | next [-]

Once this starts being actual pain, we will each vibe the replacement index creator (git already supports replacement objects), for back-forth conversion, populated on pack and object indexing.

For massive perf and mem use damage. But oh well. And then we will wait for official version

▲

windsurfer 9 hours ago | parent | prev | next [-]

Since SHA-1 is already broken (just expensive in terms of GPU-time), then the text "please see commit <sha1>" is also already broken.

▲

Dylan16807 9 hours ago | parent | next [-]

You can't attack an existing normal commit.

But also collisions there aren't a big deal. People will cite short hashes when referring to things and that's not "broken".

	▲	windsurfer 5 hours ago \| parent [-]
		If it's an existing commit and you're already converting the repo, you can just convert the commit messages as well.

▲

schacon 8 hours ago | parent | prev [-]

That is essentially only a second preimage problem, which is basically impossible.

	▲	7 hours ago \| parent [-]
		[deleted]

▲

schacon 8 hours ago | parent | prev [-]

There are plans to keep sha1s around in a database, but as far as I know, no way to transmit those, so they seem specific to individual forges. They can be recomputed, sure, but again, any signatures break and it's possible that in the case of an actual replacement, the recomputation is now wrong and not easily comparable. So what is the point?

	▲	purpleidea 7 hours ago \| parent [-]
		This is not about forges, it is about the repo I have in a folder on my computer. The sha1 hashes shouldn't go away. Yes the forges also need to support this.