1. 42
  1. 6

    Command line options to convert to new hashes look weird. “Frobnicate blobs”, “climb subtrees”, “use shovels”, “carbon offsets”.

    1. 13

      I think it’s intended as a joke/funny example.

      1. 1

        Yes. Other parts that made me chuckle:

        Somewhere out there is certainly some developer who actually memorizes SHA‑1 hashes


        The value of write-only repositories is generally agreed to be relatively low

      2. 10

        I think it’s tribute to people creating fake Git manual entries with Markov chains and a 17th century forestry book (and the resulting texts being barely distinguishable from the original man pages).

        (I can’t find the original “fake” generator, but here is a similar page: https://git-man-page-generator.lokaltog.net/)

        1. 6

          I was interested in how fossil handled the SHA1 transition and found it nicely explained here if anyone is interested: https://fossil-scm.org/home/doc/trunk/www/hashpolicy.wiki

          1. 5

            Would it make sense to use concat(sha1, sha256) hash algorithm? This wouldn’t change the prefixes while improving the strength of an algorithm (by including SHA256 in a hash).

            1. 10

              No, because trees are hashes-of-hashes, so if you change anything at all about them, their hashes will change, and therefore commit hashes will change.

              1. 2

                I don’t think that a different the prefix is a problem anyway. The problem is backwards compatibility and doing a large overhaul of the entire source code, which contains the hashes as hardcoded arrays.

              2. 2

                I realize there were existing constraints, but this seems like the sort of thing multihash (which I stumbled across from IPFS) would avoid.