Re: [PATCH 1/3] retain reflogs for deleted refs

From: Jeff King <peff@peff.net>
Date: Jul 20, 2012, 15:50 UTC
Message-ID: <20120720155032.GC2862@sigill.intra.peff.net>
In-Reply-To: <7vliietp4u.fsf@alter.siamese.dyndns.org>

On Fri, Jul 20, 2012 at 08:42:57AM -0700, Junio C Hamano wrote:

Show 16 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > But it would mean that you cannot naively run
> >
> >   echo $sha1 >.git/refs/heads/foo
> >
> > anymore. I suspect that the packed-refs conversion rooted out many
> > scripts that did not use update-ref and rev-parse to access refs, but
> > the above does still work today. So I suspect there would be some
> > fallout. Not to mention that older versions of git would be completely
> > broken, which would mean we need a lengthy deprecation period while
> > everybody upgrades to versions of git that support the reading side.
> 
> We have that "core.repositoryversion" thing, so we could treat it
> just like "update-index --index-version 4" to make it a "flag day
> event for each repository, on the day of end-user's choice".

True. The code to handle both cases would be pretty nasty, though, mostly because we do not isolate the filesystem calls at all right now (i.e., there are a lot of calls to git_path("logs/%s", refname) in the code. Which is probably not too bad, but there are a lot of implicit reverse-conversions (e.g., walking the hierarchy and assuming that the path you find is a refname).

If we are seriously considering doing this for the full refs namespace anytime soon, then I'd be tempted to hold off the reflog graveyard until then. The code would be a lot simpler and less error-prone if we didn't have to convert between the namespaces (you would simply not get the reflog retention behavior in the old repositoryformatversion).

-Peff