31
Git 3.0's upcoming SHA-256 default will be a costly mistake - gitbutler.com (blog.gitbutler.com)
submitted 6 days ago by to c/technology@lemmy.world
9 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 22 points 6 days ago (8 children)

The root problem is that there is no backward compatibility - you can't mix the two. Why is that is beyond me.

  • permalink
  • fedilink
  • source
  • hideshow 8 child comments
    •
  • [–] 14 points 6 days ago (6 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 5 points 6 days ago (2 children)

    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.

    Well, like it or not, they are used. And not so rarely. Now, rehashing will probably work, but it will require every project to do that. If you use more than one submodule which is not under your control, you have again mixed hashes that you can't fix easily.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 days ago (1 child)

    Sorry for the late reply.

    Again, do you have any actual evidence that SHA-256 repositories in version 3.0 won't be able to reference SHA-1 repositories as submodules?

    Based on the design doc it looks like git will include both hashes during the transition, specifically to allow two-way communication with SHA-1 remotes. You may not be able to include a random stranger's SHA-1 submodule via a shallow clone, but just doing a full clone sure as heck looks like a supported usage.

    https://git-scm.com/docs/hash-function-transition

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 5 points 6 days 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
    •
  • [–] 2 points 6 days ago (1 child)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 5 points 6 days 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