Hi, On Sat, 10 Mar 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > Basically, I am saying that this whole bundle concept is not thought > > through, that it is too loosely defined, and that it will result in > > unmet expectations sooner or later. (Which usually means sooner.) > > Earlier I thought you said that bundle had a clearly defined semantics, > which I did not quite understand, but now you are agreeing with me... git-bundle (as is in "next") has clearly defined semantics. But the bundle concept is not thought through. Obviously, the clearly defined semantics of git-bundle do not match what people want to use bundles for. > > So, either we have to rethink how to handle prerequisites (so that > > only those are checked which are strictly necessary for _the one_ ref > > you are updating), or we have to make it _very_ obvious to (human) > > users of git-bundle that you should _not_ bundle two unrelated -- or > > only remotely related -- refs into one bundle. > > I've been wondering if we can define prereqs per listed head. That is a substantial change, and it makes creating a bundle potentially very expensive. We would have to find out reachability for every boundary commit from each ref. Granted, we could do that while finding the boundary objects, but we only have 28-16 bits left to store from which ref the commit is reachable, which means only 12 refs, and if you have more (which is likely when you say "--all" and have a reasonable number of tags) you need to allocate a bitfield for the remaining refs _for each_ traversed commit's parents. So I wonder if there is not a better way. 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