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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html