Hacker News Reader

Comment by purpleidea | Hacker News Reader

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.

View on HN

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...

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

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.

... 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.

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

If we don't need to migrate repos to sha256 them why do we need to change git to use sha256?

You keep the old repo for archival purposes and work with the new one.

Some companies survive longer than five years. So old repos are also active ones.

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

Note that there exists multiple ways to continue to lookup SHA1s in a SHA256 repo.

One example is to maintain git-replace refs for the rewritten SHAs but there also exist config flags to enable object format compatibility extensions that help translate the SHAs back and forth.

https://git-scm.com/docs/git-replace

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

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?

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.

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

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".

If it's an existing commit and you're already converting the repo, you can just convert the commit messages as well.

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

Reply on news.ycombinator.com