> > 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 > How does everybody feel about the following: - Leave git-basis as a small perl script. - Add a -b/--basis option in git-bundle that calls git-basis. Any objects mentioned in the output would be excluded from the bundle. Multiple --basis options will call git-basis once with several arguments to generate the intersection of specified bases. - (maybe) Add an option "--update-bases" to automatically call git-basis --update after the bundle is created successfully. - Change the syntax a bit so git-basis --show does what git-basis alone does now (because the user will no longer need to interact with that command). There's still plenty of potential for improvements, like a --gc mode to clean up basis files, a --rewind option to undo an incorrect --update, or improvements in the way it calculates intersections, but I think that with these changes the system is as simple as possible while maximizing flexibility, utility, and usability. Adam -- 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
