Thread (18 messages) 18 messages, 4 authors, 2021-03-26

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

flat view

From: Jeff King <hidden>
Date: 2021-03-18 22:55:21

On Thu, Mar 18, 2021 at 04:31:24PM -0600, Martin Fick wrote:
On Thursday, March 18, 2021 9:58:56 AM MDT Han-Wen Nienhuys wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help