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

From: Jeff King <peff@peff.net>
Date: Jul 20, 2012, 15:07 UTC
Message-ID: <20120720150726.GA2862@sigill.intra.peff.net>
In-Reply-To: <20120720144337.GA31946@sigill.intra.peff.net>

On Fri, Jul 20, 2012 at 10:43:37AM -0400, Jeff King wrote:

Show 16 quoted lines

> > I think the work-around indicates the need for regular users to be
> > able to also discover, prune and delete these logs.  Do we have
> > "prune reflog for _this_ ref (or these refs), removing entries that
> > are older than this threshold"?  If so the codepath would need to
> > know about the graveyard and the implementation detail of the tilde
> > suffix so that the end users do not need to know about them.
> 
> We do have it: "git reflog expire --expire=now deleted-branch" is the
> right way to do it. Unfortunately, it does not work with my patch. The
> dwim_log correctly notes that a reflog exists (because it checks that
> the "graveyard" version of the ref exists), but then expire_reflog does
> not correctly fallback when opening the log (it usually has to do the
> _reverse_ translation, because it gets the graveyard log name from
> for_each_reflog, and has to find the correct lock).
> 
> I'll fix it in my re-roll, and then have t7701 use it.

I noticed I ignored the "discover" and "delete" parts of your paragraph. As far as deletion goes, I think we can ignore it; expiring all entries is equivalent.

Discovery is harder. Certainly these should not show up in normal ref-listing output. I'd be content to leave them slightly hidden as a first step, and people who know they are looking for the pre-deletion contents of the "foo" branch can access it by name. Probably a second step would be a fancier interface to help with listing and resurrecting dead branches, possibly including branch config.

In other words, I want to focus on getting the ref-level plumbing right, and then we can care about the porcelain later.

-Peff