On Tue, 11 Sep 2007, Andreas Ericsson wrote:
> Nicolas Pitre wrote:
> > If you want to retrieve a lost branch tip, it is certainly not an old one,
> > otherwise you'd certainly have forgotten about it. So why not simply
> > consulting the reflog, which, incidentally, was designed exactly for that
> > usage scenario, i.e. retrieving lost branches? It is certainly easier than
> > wadding through a pile of random loose commits.
> >
>
> So maybe we should deprecate git-lost-found? Since that was *also* designed
> for the scenario where one has lost a branch tip.
... by incident, since it is rather suboptimal at that. And it is meant
to rescue dangling blobs too, which the reflog won't see. So there is
no reason to deprecate lost-found as it still has some usefulness, but
there is a better way to retrieve lost branches now.
> > > To me, the ability to say "HEAD@{35}" (or "HEAD@{650}"...) is not
> > > fundamental,
> >
> > Maybe it should?
> >
>
> Why? I'd have no idea where I'd end up. I can't remember exactly what I
> did to my branch head more than 5 revs (or 15 minutes) ago, and since
> the reflog provides "subject-by-action" instead of "subject-by-commit"
> it's, imo, much less usable for recovering lost branch-heads.
Then, maybe you would be interested by 'git log -g' if 'git reflog'
isn't verbose enough for you.
> Had I only remembered the exact wording in the commit-subject I'd
> have found it a lot faster with "git-lost-found | grep wording" than
> I would have if I'd used the reflog from the start.
Maybe 'git log -g -Swording' then? Or any other log options you like.
> Anyways, problem solved now. I'll just expire the reflog before I prune
> and continue to use git-lost-found to recover loose tips when I need it.
As you wish.
Nicolas
-
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
