On Thu, 14 Feb 2008, Jeff King wrote:
> 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.
> (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.
> 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.
> 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.
> > > 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}.
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
