On Wed, 18 Oct 2006, Jeff King wrote: > > I never used BK, but my understanding is that it was based on > changesets, so a bundle was a group of changesets. Yes. > Because a git commit represents the entire tree state, how can we avoid > sending the entire tree in each bundle? That's not the problem. That's easy to handle - and we already do. That's the whole point of the wire-transfer protocol (ie sending deltas, and only sending enough to actually matter). > The interactive protocols can ask "what do you have?" but an email > bundle is presumably meant to work without a round trip. Right, but they can do exactly what bk did: you have to have a reference to what the other side has. In git, that's usually even simpler: you'd do git send origin.. and that "origin" is what the other end is expected to already have. Of course, if you send an unconnected bundle (ie you give an origin that the other end _doesn't_ have), you're screwed. In other words, to get such a pack, we'd _literally_ just do something like git-rev-list --objects-edge origin.. | git-pack-objects --stdout | uuencode and that would be it. You'd still need to add a "diffstat" to the thing, and tell the other end what the current HEAD is (so that it knows what it's supposed to fast-forward to), but it _literally_ is that simple. "plug-in architecture" my ass. "I recognize this - it's UNIX!". Linus - 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