Jonathan Nieder [off-list ref] writes:
Casey Dahlin wrote:
quoted
On Tue, Dec 07, 2010 at 11:45:20AM -0600, Jonathan Nieder wrote:
quoted
Casey Dahlin wrote:
quoted
quoted
quoted
Could commits made onto a detached head also show up here? Or is that
better thwarted with another mechanism?
I think that's better thwarted with the HEAD reflog:
$ git log -g HEAD
I was more worried about changes that were made onto a detached head,
and then the head was reattached, leaving the new commits dangling.
But isn't that exactly what a detached HEAD is for? If one wants
the experiments one does on detached HEAD to be kept around "just
in case", wouldn't it make more sense to give them a (branch) name so
they can be separated from one another?
What are you arguing after giving a correct answer. "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?
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