Git 3.0 will make SHA-256 the new default content hashing algorithm and it will be an incomprehensibly expensive and ultimately valueless and avoidable global nightmare.
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.
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.)
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.
Where do you see that submodules won’t cause headaches?
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.)