DomeGuy comments on Git 3.0's upcoming SHA-256 default will be a costly mistake

Technology

89,627 readers

13,793 active

3,105 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related news or articles.
Be excellent to each other!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
Check for duplicates before posting, duplicates may be removed
Accounts 7 days and younger will have their posts automatically removed.

Approved Bots

founded 3 years ago

moderators

[–] DomeGuy@lemmy.world 5 points 1 month ago (2 children)

Further reading that casts doubt on even submodules breaking:

https://www.deployhq.com/blog/git-3-0-on-the-horizon-what-git-users-need-to-know-about-the-next-major-release

It sounds like the new default is specifically to push GitHub et al to support SHA-256. Which they either will, or they will fork git and continue on with SHA-1 forever.

permalink

fedilink

source

parent

hideshow 2 child comments

[–] Mihies@programming.dev 2 points 1 month ago (1 child)

Where do you see that submodules won't cause headaches?

permalink

fedilink

source

parent

hideshow 1 child comment

[–] DomeGuy@lemmy.world 5 points 1 month ago

The bit about "comparability". Where do you see that they will? (I mean, aside from the original article that claimed it without evidence.)

A submodule is "just" a pointer to a specific commit in an external repo. It was at one point entirely done via shell scripts, and unless I missed an update is still obnoxiously slow compared to the rest of git.

I can't fathom why the SHA-256 support for submodules would do more than just treat the SHA as a foreign key.and go from there. We'd potentially be in trouble if SHA-1 support is being removed, but I don't see any reason why git would do something so stupid.

(I honestly can't fathom why SHA-256 hashed commits couldn't be the children of SHA-1 commits. A bunch of reasons why you may not WANT to, but that's a separate concern that seems like it'd be outweighed by comparability.)

permalink

fedilink

source

parent