Hi, Michael Haggerty wrote: > The status quo is that we have a single reference back end consisting of > loose references sitting on top of packed references. > > But really, loose references and packed references are two relatively > independent reference back ends [1]. We just happen to use them layered > on top of each other. > > This suggests to me that our current structure is best modeled as two > independent reference back ends, with a third implementation of the same > reference API whose job it is to compose the first two. [...] > [1] Forget for the sake of this discussion that we can't store symbolic > references as packed refs. I find it hard to forget that. ;-) More to the point, the trouble with loose refs and packed refs as independent reference backends is that neither has very good performance characteristics. Enumerating many loose refs is slow. Adding a new packed ref to a large list is also slow. Git currently uses both loose and packed refs in a way that allows each to overcome the limitations of the other, and the fact that it involves two on-disk data structures seems to me like an implementation detail of how it achieves that. So I believe most git code should not have to know about the difference between loose and packed refs (or the upper and lower layer) to allow the details of the layering can be tuned in low-level ref handling code. On the other hand, from a code structure perspective I can easily believe that implementing some subset (or maybe even all) of the reference backend API for loose refs and packed refs separately and providing a separate file describing how to compose them might be the cleanest way to write this code. It's more general layering that seems to lie in the direction of madness. Maybe I'm wrong and people will find lots of use for combinations like * loose refs shadowing an sqlite database * tdb shadowing mysql * etc It's easy to prove a naysayer wrong with code and I don't want to discourage that. For the topic at hand it's relevant because packed-refs have properties that make some operations (certain deletion/ref creation combinations) much less fussy than loose refs, and it would be nice to be able to take advantage of that. In the long term I would like to see git taking advantage of that when someone tries to fetch refs with names that would conflict on the filesystem (e.g., topic, topic/a, topic/b). Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html