Junio C Hamano wrote:
> "git log -g HEAD"
> keeps track of what was at the tip of HEAD, be it pointing at a branch or
> pointing diretly at a commit in a detached state, no?
Yes.
1. Imagine I have an interesting branch and delete it:
$ git branch interesting $(lots of hard work)
$ git branch -D interesting
Oops. If I want to recover that branch, I may have a lot of digging
to do in the HEAD reflog. It may not be there are all. Your patch
mitigates that by allowing a simple "I didn't mean that" command.
$ git branch --undelete interesting
2. Great. Another way to lose a line of development, as Casey
mentioned, is to not give it a branch name in the first place:
$ git checkout HEAD^0
...
$ git checkout something-else
Oops. Well, not so bad. If I want to recover my old work, I can
simply use
$ git checkout HEAD@{1}
3. Now suppose I was not paying attention and made the mistake
from (1) or (2) a week ago and didn't realize it. Now I want to
get back that code.
If it was situation (1), I can remember the name of the branch
and do
$ git branch --undelete interesting
No problem [1]. If it was situation (2), I need to dig through the
HEAD reflog. As Jeff explained, it is possible to script something up
to help organize the search. I think Casey was suggesting doing that
work at HEAD-reattachment time instead, so you could do
$ git branch --undelete-detached-head=old-head
to recover the last line of development made without a branch;
my response was that if this ends up frequently being useful
then I suspect something is wrong with the workflow.
Hoping that is clearer,
Jonathan
[1] as long as the branch name was not reused
--
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