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,

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to