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