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

[Junio C Hamano <gitster@pobox.com>]

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

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

You can set both expiry criteria to the same timestamp, unless you feel
"dead-end experiment is _more_ important", so I frankly don't see a strong
need to explain.  The two expiry setting came from the discussion in:

  http://thread.gmane.org/gmane.comp.version-control.git/34653/focus=34734

I can understand the "Oh, I made a commit that adds a huge garbage blob by
mistake---I want to get rid of it from my odb" use case.  It may go like
this:

    # starting from master
    git checkout maint ; did something
    git checkout next ; did something
    git checkout master
    git add huge-gunk ; git commit ; oops
    git reset --hard HEAD^

    git gc --expire-unreachable=now

In the current behaviour, HEAD reflog loses everything that is not
reachable from the current tip, just like the reflog for ordinary
branches.  You would lose the last pointer to the commit made by mistake
and the huge blob will immediately be kicked out from the odb.

But then I have to lose the record that I was working on 'next' before
coming to master, while I still have the record that says I was on
'maint'.  That is what "git checkout -" (and git log -g HEAD) will give us
after the above sequence.  I cannot explain how that could possibly be a
sane behaviour to the users.

It would be nicer to lose entries that talk about commits that do not
appear in history of any ref, and we can have the best of both worlds.
The patch does not do that, but it should be easy to implement.  Instead
of marking from the tip of the ref that the reflog we are expiring is for,
when expiring HEAD reflog, you would mark from the tips of _all_ the refs
(and you would need to clean up afterwards the same way).