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

[Jeff King <peff@peff.net>]

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

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