Re: Distinguishing FF vs non-FF updates in the reflog?

From: Jeff King <peff@peff.net>
Date: Mar 18, 2021, 22:54 UTC
Message-ID: <YFPaMj9PVfXlp4bL@coredump.intra.peff.net>
In-Reply-To: <21556546.pz8f0XPdgJ@mfick-lnx>

On Thu, Mar 18, 2021 at 04:31:24PM -0600, Martin Fick wrote:

Show 7 quoted lines

> On Thursday, March 18, 2021 9:58:56 AM MDT Han-Wen Nienhuys wrote:
> > The bitmaps are generated by GC, and you can't GC all the time. 
> 
> I believe that I recently saw an effort to make this incremental, perhaps 
> related to the geometric repacking series? If that were the case, you could gc 
> much more often cheaply. Perhaps it could be something done on every upload at 
> some point the way that reflog effectively does on every update?

That geometric repacking work is leading up to having a bitmap for a multi-pack-index. Which will make them _cheaper_, but still not especially cheap (because we've reordered the objects corresponding to each bit, and also because our writing process still does a lot of O(nr_commits) work).

In the very long run, I think the way out would be to stop using pack or midx ordering as the basis of the bitmap, and instead have a stable object ordering that can be appended to. That would allow true incremental generation of the bitmaps (leaving old ones in place, and just adding a new ones to represent new commits). But that's such a big departure from the status quo that having a midx bitmap seemed like a more attainable middle ground in the meantime.

-Peff