Re: Removing Partial Clone / Filtered Clone on a repo

From: Tao Klerks <tao@klerks.biz>
Date: Jun 2, 2021, 05:04 UTC
Message-ID: <CAPMMpoiReALTrn5R2VK6FK+15XgOJd-8r2rZsmQZXbH0R1kq+A@mail.gmail.com>
In-Reply-To: <CAPMMpoi_XSLJXtxGD74r-uoao+Z6Xcg8xkXuZCYix4=tBWD8rw@mail.gmail.com>

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:

Show 14 quoted lines

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