On Thu, 14 Feb 2008, Jeff King wrote:

quoted text
> On Thu, Feb 14, 2008 at 11:16:20AM -0500, Nicolas Pitre wrote:
> 
> > > 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?

I typically have lots of branches.  Many of those are fairly dynamic -- 
they come and go.  Keeping reflogs for them would only clutter the 
reflog space, especially when the same names are reused.  I prefer to 
have a clean reflog for the currently alive branch of a given name 
rather than having a log of anything that occurred under that name.  And 
if I really want to find out about that old branch then there is always 
the HEAD reflog.

quoted text
> (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).

Sure, and that limitation is IMHO quite sane.  I don't think it is worth 
stretching it just for the convenience of having refs for deleted 
branches elsewhere than from the HEAD reflog.

quoted text
> 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.

And if you delete it then you can retrieve it again from its origin.  
If, on the other hand, you _checkout_ that branch (it now entered the 
HEAD reflog), and _commit_ to it (which commit would be unreachable 
from other sources) then _that_ is a ref worth keeping a log of.

quoted text
> Secondly, you _can_ change a ref without it being the HEAD. Try
> 
>   git branch -f foo bar

Sure.  And what information would become unreachable if you delete 'foo' 
at that point?  The 'bar' commit is not lost, and likely to still exist 
in some other reflog.

quoted text
> > > 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.

This is trivial.

$ git log -g HEAD | grep -C2 "^Reflog.*moving from branch to"

If the first hit is HEAD@{x} then your branch@{0} is just HEAD@{x+1}.

quoted text
> 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?

The naming of deleted reflogs when new branches with same name are 
created, or the concatenation of entries for unrelated branches that 
might happen to have existed under the same name.

And because the relevant entries are already in the HEAD reflog anyway, 
and trivially retrieved as demonstrated above, I don't think it is worth 
adding any additional complexity for what is only a convenience feature 
that is not supposed to be used many times a day after all.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html