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.
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. So, I think the problem is that the person did a flurry of
creation/ deletion/ rebases, and wants to reach one particular commit
she remembers seeing sometime in the past (possibly in refs/remotes/*,
in which case HEAD reflog wouldn't have logged it). More than adding
a graveyard to provide hard-to-dissect information, I'm interested in
tooling support for the information we already have.
So, I want to search all reflogs for this particular commit I've seen:
git log -1 --relative-date -g :/quuxery
Doesn't work. I can search only search one reflog at a time:
git log -1 --relative-date @@{0}^{/quuxery}
Isn't this much too painful?
Our "default" reflog command displays useless information: why should
I see HEAD@{1} followed by HEAD@{2} and other numbers in ascending
order? What is the point of that when the abbreviated sha1 is already
shown in the first field? I use the following alias for reflog:
rfl = log --oneline --relative-date -g
but it could easily be better.
There are tons of other issues: for instance, after an
interactive-rebase, 'git checkout -' doesn't take me back to the
previous branch (because the parser for @{<N>} is broken). There are
way too many SHA-1s polluting the description, which can easily be
replaced by a git-describe output. When I git checkout @~1, my prompt
doesn't scream the sha1; it shows me upstream-error~1, which makes a
lot more sense.
I was under the impression that heavy reflog users would be more
interested in fixing these issues before dumping even more data onto
the user.
--
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