Hi, On Sun, 11 Mar 2007, Mark Levedahl wrote: > Johannes Schindelin wrote: > > git-bundle (as is in "next") has clearly defined semantics. > > git-bundle on next with the patch in > <Pine.LNX.4.63.0703091726530.22628@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> > works well enough for me, but absent that latter patch is too punishing. I don't want to punish you! But I want to prevent "Huh?" moments early on. > > I've been wondering if we can define prereqs per listed head. > > Currently, a bundle has a single pack. The bundle's prerequisites > are that pack's dependencies. Splitting prerequisites per head requires > either creating one pack per head or unpacking at the receiving and and > extracting only the objects needed for the selected head. I'm not sure > that either is warranted, and my uses of bundle do not require this > regardless. You can just store the pack and update the ref (at least as long as the pack is not thin): we have a long-standing tradition of guaranteeing the integrity of commit chains _only_ when the commits are reachable by at least one ref. > I think we need to restate purpose here. git-bundle is an alternate > transport mechanism: git-bundle + git-fetch over sneakernet allows doing > what git-push or git-fetch can do when directly connected. But would that not mean that we expect the user of the bundle to update _all_ refs contained in the bundle? > However, there are limitations due to the lack of direct connect, > specifically the user of git-bundle needs to specify the prerequisites > as the protocol cannot negotiate these. The exchange needs to be robust > in that git-bundle+git-fetch must never result in leaving a repository > in a corrupted state: the current prerequisites list + use of git-fetch > seem to satisfy this. Yes. I think we definitely need to ensure the integrity _before_ updating the refs (and not rely on the prereqs in the bundle). And yes, that means I changed my mind from when I argued against your use of fsck, and _for_ prereqs. > With appropriate remote settings in .git/config, I can have git-fetch > get all branches, or all branches and tags, and never complain when no > update is required for something. Makes sense. > While it is possible to fetch a particular ref from the bundle rather > than taking all, the monolithic pack structure and protocol dictates > that you will get all objects regardless. ... but a subsequent git-gc will strip them away. > At some point, we have to make a clear distinction between what rules > the protocol should enforce for "correctness" vs what an "intelligent" > use of bundle is, and not try to enforce the latter in the software. Concur. But I think that we have to make sure that the "correctness" enforcing means that you do not end up with something that people want to use for what it cannot be used for. > Bottom line, I strongly advocate Dscho's last patch + what is on next be > promoted to master. We can revisit how well it is working and refine it > after it gets some usage from others defining additional use-cases. FWIW my plans are to make the pack thin _only_ when there is only one prereq and/or ref in the bundle (this prevents a _wanted_ object being deltified against a not-wanted object). Also, as mentioned above, I think that we have to check that "git rev-list --objects <new-refs> --not --all" does not result in missing objects. 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