• 0 posts
  • 4 comments
Joined 2 years ago
Cake day: September 15th, 2024
  • 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.)

  • I read that whole article, and aside from an unsourced statement that GitHub et al will need “new and distinct servers” exactly zero of that seemed to support the thesis that a SHA-256 default was going to be “expensive”.

    Submodules are not the preferred way to incorporate third-party code for any environment I know. And while web-exposed URLs for management tools like Jira or AzureDevOps will need to adapt before the new default can be used, doing so even with a wholesale re-hashing of every commit isn’t technically difficult.

    What would be terrible and dangerous would be if git 3.0 entirely dropped SHA-1 support. But just as you’re free to keep on using “master” instead of “main”, i expect that extant projects will still be supported until a version after every major project has converted to SHA-256 or what have you.