Subject: Re: http-protocol question

From: Jeff King <[email-masked]>
Date: Tue, 2 Dec 2014 00:52:29 -0500

On Tue, Dec 02, 2014 at 04:47:50PM +1100, Bryan Turner wrote:

> > There is a practical reason to care. Ref deletion will also delete the
> > reflog, leaving no trace of the reachability. Whereas a non-fast-forward
> > push could be resolved by looking in the reflog.
> 
> A fair point. I had mistakenly thought that reflogs would survive the
> ref's deletion and be "pruned" as part of garbage collection, but a
> quick test shows that, as I'm sure you already know, that's not true.

I wish it worked that way. Unfortunately there are complications with
keeping the old reflogs in place, because they sometimes cause conflicts
with new refs being created (e.g., a reflog in ".git/logs/refs/heads/foo"
would prevent ".git/logs/refs/heads/foo/bar" from being created). I had
some patches long ago to try to keep a "reflog graveyard" around, but
they were quite invasive, and there were some corner cases that caused
weird errors.

Handling this sort of D/F conflict more gracefully is one of the things
I'd like to experiment with once we have pluggable ref backends (I think
we'll also disallow "foo/bar" if "foo" exists, but the storage could at
least keep the reflogs around).

-Peff