On Fri, Dec 05, 2014 at 03:36:18PM -0700, Jesse Hopkins wrote:
> #Create the bundle
> git bundle create out.bundle --all "--since=<last_bundle_date>"
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html