Re: git bundle vs git rev-list

On Fri, Dec 05, 2014 at 03:36:18PM -0700, Jesse Hopkins wrote:

Others pointed out that a bug in the handling of --since may be the culprit here. However, I'd encourage you to use actual sha1s, as they are going to be more robust (especially in the face of any clock skew in the commit timestamps).

You should be able to follow a procedure like:

  1. On day 1, create a bundle from scratch:

       git bundle create out.bundle --all

  2. Before you send it out, record its tips in the local repository
     for later reference:

       git fetch out.bundle +refs/*:refs/remotes/bundle/*

  3. On day 2, create a bundle from the previously recorded tips:

       git bundle create out.bundle --all --not --remotes=bundle

  4. Update your tips in the same way:

       git fetch out.bundle +refs/*:refs/remotes/bundle/*

and so on for day 3 and onward.

Note that this is not the only way to store those tips (I just did it using git refs because it's simple to manipulate). You could also just store it in a file:

      # checkpoint
      git ls-remote out.bundle | cut -f1 | sort -u >tips

      # make incremental bundle
      git bundle create out.bundle --all --not $(cat tips)

This also makes it easy to recover if the other side ever gets out of sync (say you create and checkpoint a bundle on the sending side, but it never makes it to the remote; how do you know where to start from?). You can always get the latest set of tips from the remote by running:

      git ls-remote . | cut -f1 | sort -u >tips

on it and then sneaker-netting the tips file back to the sender.

-Peff