Re: Keeping reflogs on branch deletion

From: Jeff King <peff@peff.net>
Date: Feb 14, 2008, 16:31 UTC
Message-ID: <20080214163101.GA24673@coredump.intra.peff.net>
In-Reply-To: <alpine.LFD.1.00.0802141103280.2732@xanadu.home>

On Thu, Feb 14, 2008 at 11:16:20AM -0500, Nicolas Pitre wrote:

Show 6 quoted lines

> > How is that any different than accumulating old entries in reflog files
> > for branches that _do_ exist? In both cases, they should be dealt with
> > via time-based pruning.
> 
> Branches that do exist are more likely to be interesting to you than 
> branches that, hopefully in 99% of all cases, you willfully deleted.

I agree that they tend to be more interesting, but the point of reflogs is to have a log of operations performed for later examination. We already have a well-defined boundary for "interesting": things that are older than N days. Why introduce another such boundary? Are your reflogs for deleted branches so large that you aren't willing to keep them?

(There is actually one reason I can think of to get rid of reflogs for deleted branches. Branch naming rules depend on which branches exist. Thus I can have "foo/bar" only if "foo" does not exist, which means that I can only have a reflog for "foo/bar" if the one for "foo" has been deleted. But that is a limitation of the current scheme for storing reflogs).

Show 7 quoted lines

> >   1. it's much more convenient to type branch@{1} than to sift through
> >      HEAD's reflog looking for checkout events and guessing which branch
> >      we were on
> 
> Exact.  But that doesn't apply to non existent branches, surely?  And 
> what would you do with the reflog of a deleted branch when a new branch 
> is created with the same name?

I think it does. Reflogs protect against changes in the "commit" space within a ref (things like "git reset HEAD^"). But there is no protection against changes in the "ref" space (like "git branch -D foo").

As for the behavior, I would just append. Your reflog would look like:

  branch@{0} - commit
  branch@{1} - create branch
  branch@{2} - delete branch
  branch@{3} - commit

The behavior would be identical for recently logged items. But instead of there being no branch@{3}, it would go back into the deleted branch.

Show 5 quoted lines

> >   2. it's possible to change a ref without it being on the HEAD, in
> >      which case the HEAD reflog doesn't contain the change.
> 
> And in those cases this can't be due to your own modifications, hence 
> nothing valuable is lost if you then delete that branch.

For one thing, just because a modification wasn't _yours_ doesn't mean it isn't valuable. It entered your repository, and therefore it may be of interest.

Secondly, you _can_ change a ref without it being the HEAD. Try

  git branch -f foo bar

Show 8 quoted lines

> > In other words, I don't see "oops, I deleted this branch and its history
> > is valuable to me" as significantly less likely than "oops, I got rid of
> > this commit and its history is valuable to me."
> 
> But you still have it, in the HEAD reflog, at least for your own 
> changes. I therefore don't see the value of having to keep named branch 
> reflogs around just for the small convenience, especially with the 
> semantic issues that comes with it.

My HEAD reflog has almost 1000 items in it. Finding out which commit would have been branch@{0} in there is non-trivial.

I agree that this information is less likely to be interesting than the usual use of reflogs. But I don't agree that the semantics are that difficult. What issues are you talking about?

-Peff