Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle

[Jeff King <peff@peff.net>]

On Wed, Jul 02, 2008 at 11:44:45AM +0200, Jakub Narebski wrote:

> Well, there is one situation where either separate git-bases program
> (which is a good start; it can be named git-bundle--bases; there are
> some precedents for that ;-)), or allowing to create 'bases' file
> without creating bundle would be good to have.  Namely situation
> where two computers are _sometimes off-line (disconnected)_.  If you
> want to transfer new commits from machine B to machine A, you would
> generate 'bases' file on machine A, then transfer this file using some
> off-line medium, then generate bundle on machine B using those bases,
> etc.

Yes, certainly it is more flexible to have them split. I find Adam's
argument the most compelling, though. Think about moving commits as a
multi-step protocol:

  1. Local -> Remote: Here are some new commits, basis..current
  2. Remote -> Local: OK, I am now at current.
  3. Local: update basis to current

git-push has the luxury of asking for "basis" each time, so we know it
is correct. But with bundles, we can't do that. And failing to update
"basis" means we will send some extra commits next time. But updating
"basis" when we shouldn't means that the next bundle will be broken.

So I think even if people _do_ want to update "basis" when they create
the bundle (because it is more convenient, and they are willing to
accept the possibility of losing sync), it is trivial to create that
workflow on top of the separate components. But I can see why somebody
might prefer the separate components, and it is hard to create them if
the feature is lumped into "git-bundle" (meaning in such a way that you
cannot perform the steps separately; obviously git-bundle --basis would
be equivalent).

But I am not a bundle user, so that is just my outsider perspective.

-Peff