Re: http-protocol question

From: Jeff King <peff@peff.net>
Date: Dec 2, 2014, 05:52 UTC
Message-ID: <20141202055228.GA2708@peff.net>
In-Reply-To: <CAGyf7-FDRS_zGQSFKhV8UGfN5GjGcyo0yCz8bcjEALYF3oj=Bg@mail.gmail.com>

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

Show 7 quoted lines

> > 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