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

From: Junio C Hamano <[email-masked]>
Date: Wed, 10 Mar 2021 16:59:43 -0800

Jonathan Tan <[email-masked]> writes:

>> 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.