On Wed, Feb 10, 2016 at 7:43 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > >> I really like this design. I'm tempted to implement it (since it >> lacks a bunch of the downsides of clone.bundle). > > Just to see people are not stepping on each others toe, implementing > slightly different components in parallel based on the same theme to > solve the same problem, it may be beneficial to have a list of a bit > more detailed breakdown of the necessary parts. > > I think possible small first steps include: > > * A new "--split-header" option to "git bundle" that allows the > command to write out two files; > > * An update to the "bundle" transport so that it understand the new > split bundle format (i.e. when you have base.bndl that refers to > pack-deadbeef.pack, you can still say "git clone base.bndl" and > "git ls-remote base.bndl"); > > * A new "--bundle-header" option to "git index-pack", which makes > it to write out the bundle header file that references the > resulting packfile in addition to the pack .idx file (this should > also be able to "fix" thin pack, and also by keeping track of the > actual "foreign" objects not just number of them, compute and > record the list of prerequisite objects in the resulting bundle > header file). > > Am I on the right track? Assuming I am, anything I missed? --bundle-header option for pack-objects so that repack/gc can create the matching .info file? I waffled on the URL in the capabilities line, but I think Peff convinced me earlier in the thread that its reasonably safe to do. So this split bundle with header URL in the capabilities sounds like a good approach, its just a matter of implementation. :) -- 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