> > Well, I have a moderately strong objection to this. > > This very much feels like adding a missing feature to "git bundle" command > itself. Why isn't it a new option to it? > Mostly because this was an easy way to accomplish the same thing. If this is popular, then it can be added to git-bundle. > For that matter, I am not sure how this integrates to a larger workflow. > You have a site (or more) to "push" your changes to, and you would need to > remember up to which revisions you have given out bundles to. To remember > which site is at what basis level, you would need an extra infrastructure > than what this separate command offers (and "I'll have a yet another layer > of wrapper to this script" is not a good answer. That wrapper can simply > read the tips from the bundle and record them without your script, and the > wrapper can use the previously recorded information to use the new bottom > refs when creating a new bundle again without using your script). The intent is to use one basis per site, not one per bundle, so the first iteration is A$ git-bundle create package.git --all B$ git-clone package.git package A$ git-bundle --update siteB < package.git and thereafter it's A$ git-bundle siteB | git-bundle create package.git --all --stdin B$ git-pull A$ git-bundle --update siteB < package.git There's no issue of remembering which site is at which basis level, because each site gets it's own basis. If you're worried about hundred of sites, this is a bad solution. I happen to be worried about three sites, so this works well for me. > > Perhaps it would be sufficient to have a new option to git-bundle. "write > basis information under this name, so that I can reuse it in the next > invocation", and "I am not giving the bottom refs to create this bundle; > read them from the existing basis with this name". It probably is easiest > to operate if these two are simply a new single option, like this... > > [...] I agree than git-bundle --basis is a better syntax than git-basis | git-bundle --stdin. I do, however, think that creating the bundle and updating the basis should be two separate steps. Mostly because the fact that I created a bundle and planned to install it on another machine does not guarantee that the resources of that bundle exist on the other machine. (I may need to stop for coffee and ... who knows?) Also, in practice, I always use the intersection of all of my remote bases when I create a bundle, and I frequently use them in places other than where I intended. Yes it's a pain to go back to git-basis --update, but it's better than trying to git-pull from a bundle that's missing objects. 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
