On Fri, Sep 29, 2017 at 06:56:28AM +0900, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > But I also think this patch may be a stepping stone to dropping "struct > > mru" entirely, and just pushing a "struct list_head mru" into the > > packed_git object itself (or of course any object you like). At which > > point we'd just directly use the list iterators anyway. > > The endgame state implied by your statement would mean that we won't > have mru_mark() and instead have these open-coded in terms of the > two calls into the list API. There only are two callers of it in > the current system, so it is not the end of the world, so I guess I > can agree that this is a good preparation step toward the longer > term goal, which says "mru API is over-engineered and what it offers > over the plain vanilla list API is almost never used except for a > few callsite; let's remove it and use the bare list API instead". Thanks, that last sentence is a good summary of my thinking (I think what I find most silly about it is that it allocates a whole extra struct per item, which is where most of the complication comes from). I had envisioned leaving mru_mark() as a wrapper for "move to the front" that could operate on any list. But seeing how Olga's patch takes it down to two trivial lines, I'd also be fine with an endgame that just eliminates it. > > I'd make the same claims here as above (both that I agree your proposed > > interface looks nicer, but also that I think we eventually do want to > > expose that this is tightly coupled with list.h). > > I agree. I just do not yet know if I fully embrace the idea that we > just should use bare list API, getting rid of the mru API. Fair enough. -Peff
