Hi, On Thu, 3 Jul 2008, Adam Brewster wrote: > > 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. > > How does everybody feel about the following: > > - Leave git-basis as a small perl script. I'd rather not. > - 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. So the only function of -b would be to fork() && exec() a _shell_ script? I don't like that at all. > - (maybe) Add an option "--update-bases" to automatically call git-basis > --update after the bundle is created successfully. Rather, have it as a feature to auto-detect if there is a ".basis" file of the same basename (or, rather ".state", a I find "basis" less than descriptive), and rewrite it if it was there. It could be forced by a to-be-introduced "--state" option to git-bundle. > There's still plenty of potential for improvements, like a --gc mode > to clean up basis files, umm, why? "rm" is not simple enough? > a --rewind option to undo an incorrect --update, Rather hard, would you not think? The information is either not there, or you store loads of cruft in the .state file. > or improvements in the way it calculates intersections, Umm. How so? > but I think that with these changes the system is as simple as possible > while maximizing flexibility, utility, and usability. I am not convinced. This sort of feature belongs into git-bundle. It certainly does not deserve being blessed by yet-another git-* command, when we are constantly being bashed for having _way_ too many _already_. Ciao, Dscho -- 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
