1. 33
  1.  

  2. 10

    I glanced at lucky-commit to see what it was doing:

    lucky-commit adds its whitespace to a 64-byte-aligned block at the very end of the commit message. Since everything that precedes the whitespace is constant for any particular commit, this allows lucky-commit to cache the SHA1 buffer state and only hash a single 64-byte block on each attempt.

    1. 3

      Did you look at the commit history :)

      1. 2

        Oh wow, that’s clever.

      2. 9

        You can prob still do a git push if you split the push into multiple stages and force use git protocol v2.

        Even at billions of commits, git uses delta compression so as long as the actual repo content don’t differ much, the packfile would be relatively small. And by pushing it in smaller batches, you only push a small set of delta.

        You can furthermore optimize the push by forcing github to run git-repack serverside by inserting 25(?) small inconsequential pushes to the repo and trigger git-gc which then call git-repack on their server. This help the repo on server to have all the correct bitmap index and commit graph and multi-pack index etc…

        1. 3

          2^28 is around 268 million. (If we were counting memory bytes, 256MB.)