Re: Removing Partial Clone / Filtered Clone on a repo

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 [off-list ref] wrote:> >
it would be good to design such a feature to have other> > custom
knobs, such as:

quoted

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