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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 15, 2010, 12:30 UTC
Message-ID: <7v4ojclwyu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4BC6D30F.5020004@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 15 quoted lines

> Am 4/15/2010 9:40, schrieb Junio C Hamano:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>> 
>>> Does not help what? What is the problem?
>> 
>> You will lose the record from HEAD reflog that records the fact that you
>> were at the tip of "next" less than "reflogexpire" but more than
>> "reflogexpireunreachable" time ago, if you run "gc" while on "master".
>> 
>> Such a pruning does not have much to do with the real reason why
>> expireunreachable would be a useful thing (namely, to prune failed
>> histories that have been rewound away faster than the history that
>> survived from reflog of individual branches).
>
> But what is the benefit?

That is a funny thing to ask. Since when not losing information is a lower priority?

> We expire reflogs so that we can garbage-collect objects.

I am tempted to say "Wrong!", but would stop at saying "We seem to have differing opinions" for now.

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.

Removing stale objects is not a goal; objects are removed merely as an effect of them becoming stale after no refs and reflog entries that matter point at them.