Re: [PATCH v8 41/44] refs.c: add a new flag for transaction delete for refs we know are packed only

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