Re: [PATCH 2/2] reflog: ignore expire-unreachable for "HEAD" reflog

From: Jeff King <peff@peff.net>
Date: Apr 15, 2010, 16:36 UTC
Message-ID: <20100415163607.GA4279@coredump.intra.peff.net>
In-Reply-To: <4BC70D75.70801@viscovery.net>

On Thu, Apr 15, 2010 at 02:58:29PM +0200, Johannes Sixt wrote:

Show 14 quoted lines

> Am 4/15/2010 14:30, schrieb Junio C Hamano:
> > A reflog consists of entries, each of which records how you got to the
> > current history by pointing to different commit objects.  Some entries
> > matter more than others do.  Dead-end experiments stop mattering faster
> > than others.  It is these _entries_ that we expire, because keeping them
> > indefinitely is a wasteful clutter.
> 
> I have no problem with this point of view, i.e., that expiration is merely
> about the entries, and that garbage-collecting objects is just a
> side-effect of removed entries.
> 
> But I don't see yet, why an entry pointing to a dead-end experiment is
> less important when it is an entry in a branch reflog than when it is an
> entry in the HEAD reflog. Care to explain?

I think it is because the reachability test is defined as "from the current ref". So if I am doing a reachability test on next@{20}, I will check whether it is in the current version of next. Unreachable things are therefore dead-end experiments. But on HEAD, if I do:

  $ git checkout topic1
  $ git checkout topic2

Then the entry for HEAD@{1} will be unreachable from the current HEAD, even though it is _not_ a failed experiment. It is just that we are no longer pointing to that branch.

I think another way of addressing the same problem would be to redefine "reachable" in this context as "reachable from any current ref".

-Peff