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