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 -- 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
