Mark Levedahl <mlevedahl@xxxxxxxxx> writes:
> ... Without, I
> can just do git bundle ... <list of refs> and those which have been
> updated get included.
I am not sure if the above is true. How are you preventing the
command from bundling everything? You must have some limiter at
the bottom, something like --since=25.hours (to account for cron
schedule skew), not just <list of refs>.
I do not think the max-age limiter works as you are expecting,
especially when merges and clock skew among committing machines
are involved (just as you are distributing from central repo, I
am assuming you are getting work back from worker-bee machines
to the central repo at some point, and doing sneakernet implies
to me that they are disconnected machines, not running ntp, but
this is just me guessing).
In any case, the semantics of --since=25.hours limiter is not
"show everything newer than 25.hours that are reachable from any
of these refs"; it is "start digging from these tips, and stop
exploring the path as soon as you hit something that is newer
than 25.hours".
It appears that for the past few days we have been spending
significant effort to make --max-count and --max-age work with
bundles, but my honest impression is they do not play well in
the real world, especially when clock skew is involved. On the
other hand, revision ranges ("include these, exclude those") are
always precise, and that is what you would want to be using,
especially from an automated script.
If I were doing a nightly script, I would probably be doing
something like this:
#!/bin/sh
yesterday=$(git bundle list-heads yesterday.bdl | sed -e 's/ .*//')
git bundle create today.bdl --all --not $yesterday
# mail it out
After sending today's bundle out, you will rotate it out to
yesterday.bdl in order to prepare for the next round. It is
likely that you would want to keep a few day's worth of bundles
for other reasons _anyway_ (say, some project members might be
out of office, or mail gets dropped, or whatever), I think the
above is a reasonably clean and easy thing to arrange.
-
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