Re: [PATCH] fetch-pack: do not mix --pack_header and packfile uri

Jonathan Tan [off-list ref] writes:

quoted

Then get_pack() can move a lot of code out of it to this helper and
just call it.  The processing the other packfile obtained by the
packfile URI mechanism out of band can open the packstream and call
the helper the same way.  When packfile URI mechanism is in use, both
invocations of the helper would get "you are not alone so fsck may
hit missing objects" bit, if fsck-objects are asked for.

That would avoid the "duplicated logic" and still allow the code to
choose the best disposition of the incoming packdata per packfile.

In an extreme case, it is not hard to imagine that somebody prepares
a very small base packfile and feed it via packfile URI mechanism,
but have accumulated so many objects that are not yet rolled into an
updated base packfile---cloning from such a repository may result in
running unpack-objects for the packfile that came out of band, while
processing the in-stream packfile with index-pack.

Hmm?

Your suggestion (as opposed to the current situation, in which we're
locked into using index-pack for the out-of-band packfiles) would make
this possible, yes.

Just to make sure, I am not interested in running unpack-objects on
oob packfiles, as they are expected to be "so old, big and not
changing that it is worth pre-generating" packfiles, so "yes the
approach would make that useless thing possible" is not a useful
criteria to judge how good the alternative approach would be.  If
the approach results in a cleaner design that gives us more
flexibility without risking unnecessary code duplication, it would
be a good sign that the approach is more sound than the direction we
took so far, though.

Thanks.