Re: can we prevent reflog deletion when branch is deleted?

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jun 1, 2013, 09:47 UTC
Message-ID: <CALkWK0mwAc0bFon7B7nw1Nbvcwdf8m2_531qtrN-r28r9F+70Q@mail.gmail.com>
In-Reply-To: <20130601090934.GA13904@sigill.intra.peff.net>

Jeff King wrote:

> Why don't the branch names have significance? If I deleted branch "foo"
> yesterday evening, wouldn't I want to be able to say "show me foo from
> 2pm yesterday" or even "show me all logs for foo, so that I can pick the
> useful bit from the list"?

Oh, I misunderstood then.  I didn't realize that your usecase was actually

    git log foo@{yesterday}

where foo is a deleted branch. Just to give some perspective, so we don't limit our problem space:

I only ever batch-delete "cold" branches: if I haven't touched a branch in ~2 months, I consider the work abandoned (due to disinterest or otherwise) and remove it. Most of my branches are short-lived, and I don't remember branch names, much less of the names of the cold branches I deleted. My usecase for a graveyeard is "I lost something, and I need to find it": I don't want to have to remember the original branch name "foo"; if you can tell everything I deleted yesterday, I can spot foo and the commit I was looking for. The HEAD reflog is almost good enough for me.

To be clear: I'm not against including branch name information; I just don't want to _have_ to remember them to find what I'm looking for.

> Defining
> a new GRAVEYARD format would need an additional field for the ref name
> of each entry, but lets us drop the other naming complexities.

Certainly. Putting it in the description will only lead to more problems (like bugs in the @{<N>} parser).

> The HEAD reflog is not sufficient for two reasons:
>
>   1. Not all ref updates were part of the HEAD reflog (e.g.,
>      refs/remotes, tags).

Would be nice to solve, but it's not a big itch in my opinion.

Show 7 quoted lines

>   2. It is not easy to see deduce which ref each entry comes from, which
>      makes "deleted_branch@{yesterday}" difficult. You can sometimes
>      deduce the branch by reading the surrounding entries (e.g., for
>      "checkout" entries), but I do not know offhand whether it can be
>      done reliably in all cases (I suspect not, given that unreachable
>      reflog entries may be pruned sooner than reachable ones, leaving
>      "holes" in the reflog's story).

Yeah, this makes sense.

> I do not necessarily disagree with your criticisms of the tooling around
> reflogs, but they are just not my interest right now, and I do not think
> working on one concept needs to hold up the other.

Oh, I didn't mean to hold up anything. I brought it up because I thought it would be of interest to heavy reflog users.