On Tue, 11 Sep 2007, Andreas Ericsson wrote:

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

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

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

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html