On Sat, Jun 01, 2013 at 01:29:07PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > I wonder if simply sticking
> > the reflog entries into a big GRAVEYARD reflog wouldn't be a great deal
> > simpler and accomplish the "keep deleted reflogs" goal, which is what
> > people actually want.
>
> Exactly what I was thinking when I read your proposal. What is the
> point of having individual graveyards for deleted branches? The
> branch names no longer have any significance, and separating the
> reflogs using branch names nobody remembers is only making
> discoverability harder.
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"?
When I suggested a big graveyard reflog, I did not mean a straight
concatenation of the deleted reflogs; I meant one which would also
record the name of the ref whose log each entry came from.
If you mean "the branch names in the filesystem don't have
significance", I agree. Using a parallel hierarchy of reflogs was an
implementation choice that let us use the same reflog format. 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.
> What is the problem we are trying to solve? Someone deletes a branch
> by mistake, and wants to get it back? There's the HEAD reflog for
> that.
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).
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).
> More than adding a graveyard to provide hard-to-dissect information,
> I'm interested in tooling support for the information we already have.
I think that is an orthogonal concern. Already with the current reflogs,
such a tool would be useful. And even without such a tool, being able to
access reflog entries of deleted branches is still useful. Even simple
things like "git branch foo deleted@{yesterday}" and "git log -g
deleted" would give a safety net. And those are supported by the
existing porcelain tooling.
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.
-Peff
--
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