Re: Removing Partial Clone / Filtered Clone on a repo

[Tao Klerks <tao@klerks.biz>]

I understand replying to myself is bad form, but I need to add a
correction/clarification to a statement I made below:

On Tue, Jun 1, 2021 at 6:54 PM Tao Klerks <tao@klerks.biz> wrote:> >
it would be good to design such a feature to have other> > custom
knobs, such as:
> > * Get only "recent" history, perhaps with a "--since=<date>"
> >   kind of flag. This would walk commits only to a certain date,
> >   then find all missing blobs reachable from their root trees.
>
> As long as you know at initial clone time that this is what you want,
> combining shallow clone with sparse clone already enables this today
> (shallow clone, set up filter, unshallow, and potentially remove
> filter). You can even do more complicated things like unshallowing
> with different increasingly-aggressive filters in multiple
> steps/fetches over different time periods. The main challenge that I
> perceive at the moment is that you're effectively locked into "one
> shot". As soon as you've retrieved the commits with blobs missing,
> "filling them in" at scale seems to be orders of magnitude more
> expensive than an equivalent clone would have been.

As I just noted in another thread, there seems to be one extra step
needed to pull this off: you need to add a *.promisor file for the
initial shallow clone's packfile, because otherwise (at least with the
2.31 client that I am using) later "git fetch" calls take forever
doing something with rev-list that I don't understand, presumably due
to the relationship between promisor packfiles and non-promisor
packfiles...