Recovering Committed Changes in a Detached Head?

Recovering Committed Changes in a Detached Head?

[Daly Gutierrez]

Is this possible after changing from the Detached Head branch to an
existing branch?  How about if I don't remember the commit SHA1 ID?

What I did, to the best of my knowledge:
1) Checked out a previous version:
> git checkout 3a5bb38a83c00f7acab573f0ec836577143200aa

2) Modified file and committed the changes in the detached branch.
> git log
 commit 92aa5381b9f7229523dba42aa94735c30f173451
 Author: Daly Gutierrez <Daly.Gutierrez@gmail.com>
 Date:   Sat Oct 8 16:20:11 2011 -0400

    Committing this in the Detached Head

3) For curiosity,
> git branch
* (no branch)
  New_Branch
  Second_New_Branch
  master

4) Changed to 'New_Branch' branch...  I no longer see the detached
branch...
 > git branch
* New_Branch
  Second_New_Branch
  master

5) Want to access the file with the changes I made in the Detached
branch, but don't know how...  PLEASE HELP?

Re: Recovering Committed Changes in a Detached Head?

[SZEDER Gábor]

Hi,

On Sat, Oct 08, 2011 at 04:58:07PM -0400, Daly Gutierrez wrote:
> Is this possible after changing from the Detached Head branch to an
> existing branch?  How about if I don't remember the commit SHA1 ID?
> 
> What I did, to the best of my knowledge:
> 1) Checked out a previous version:
> > git checkout 3a5bb38a83c00f7acab573f0ec836577143200aa
> 
> 2) Modified file and committed the changes in the detached branch.
> > git log
>  commit 92aa5381b9f7229523dba42aa94735c30f173451
>  Author: Daly Gutierrez <Daly.Gutierrez@gmail.com>
>  Date:   Sat Oct 8 16:20:11 2011 -0400
> 
>     Committing this in the Detached Head
> 
> 3) For curiosity,
> > git branch
> * (no branch)
>   New_Branch
>   Second_New_Branch
>   master
> 
> 4) Changed to 'New_Branch' branch...  I no longer see the detached
> branch...
>  > git branch
> * New_Branch
>   Second_New_Branch
>   master
> 
> 5) Want to access the file with the changes I made in the Detached
> branch, but don't know how...  PLEASE HELP?

git reflog to the rescue.  For your example above it will output
something like this:

  deadbeef HEAD@{0}: checkout: moving from 92aa5381b9f7229523dba42aa94735c30f173451 to New_Branch
  92aa5381 HEAD@{1}: commit: Committing this in the Detached Head
  3a5bb38a HEAD@{2}: checkout: moving from master to 3a5bb38a83c00f7acab573f0ec836577143200aa
  deafbabe HEAD@{3}: ...
  ...

There you see the first line of the commit message from your "lost"
commit, and you can do

  git checkout -b lost_detached_head 92aa5381

and you get a branch pointing to that commit you made while on
detached head, and you can work with it as usual.


Best,
Gábor

Re: Recovering Committed Changes in a Detached Head?

[Martin Fick]

>git reflog to the rescue.  For your example above it will output
>something like this:
>
>deadbeef HEAD@{0}: checkout: moving from
>92aa5381b9f7229523dba42aa94735c30f173451 to New_Branch
>  92aa5381 HEAD@{1}: commit: Committing this in the Detached Head
>3a5bb38a HEAD@{2}: checkout: moving from master to
>3a5bb38a83c00f7acab573f0ec836577143200aa
>  deafbabe HEAD@{3}: ...
>  ...
>
>There you see the first line of the commit message from your "lost"
>commit, and you can do
>
>  git checkout -b lost_detached_head 92aa5381
>
>and you get a branch pointing to that commit you made while on
>detached head, and you can work with it as usual.

While rflog is cool, I can't help but think that git could be even more helpful for these scenarios.

First, maybe git could create refs for these automatically, perhaps with a name like orphans/1?  Maybe these refs would only be visible via git branch --orphans.

-Martin
Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum

Re: Recovering Committed Changes in a Detached Head?

[Joel C. Salomon]

On 10/08/2011 06:00 PM, Martin Fick wrote:
>> git reflog to the rescue.
<snip>
>> There you see the first line of the commit message from your "lost"
>> commit, and you can do
>>
>>  git checkout -b lost_detached_head 92aa5381
>>
>> and you get a branch pointing to that commit you made while on
>> detached head, and you can work with it as usual.
> 
> While rflog is cool, I can't help but think that git could be even more helpful for these scenarios.
> 
> First, maybe git could create refs for these automatically, perhaps with a name like orphans/1?  Maybe these refs would only be visible via git branch --orphans.

Creating these "orphan" refs would require the equivalent of (part of)
git-fsck; I can't imagine that could be imposed without significant
overhead on too many operations.  I think you'd be better off wrapping
git-fsck in a script that can create these branches.

--Joel

Re: Recovering Committed Changes in a Detached Head?

[Martin Fick]

"Joel C. Salomon" <joelcsalomon@gmail.com> wrote:

>On 10/08/2011 06:00 PM, Martin Fick wrote:
>>> git reflog to the rescue.
><snip>
>>> There you see the first line of the commit message from your "lost"
>>> commit, and you can do
>>>
>>>  git checkout -b lost_detached_head 92aa5381
>>>
>>> and you get a branch pointing to that commit you made while on
>>> detached head, and you can work with it as usual.
>> 
>> While rflog is cool, I can't help but think that git could be even
>more helpful for these scenarios.
>> 
>> First, maybe git could create refs for these automatically, perhaps
>with a name like orphans/1?  Maybe these refs would only be visible via
>git branch --orphans.
>
>Creating these "orphan" refs would require the equivalent of (part of)
>git-fsck; I can't imagine that could be imposed without significant
>overhead on too many operations.  I think you'd be better off wrapping
>git-fsck in a script that can create these branches.
 
Is there another way to create orphan refs than by doing a checkout and leaving the orphan behind?  I guess a rebase or other branch rewinding operations, but shouldn't it already know on those that that if it alters anything, it will create an orphan?  Git already checks for to see if it is leaving orphan refs behind on a checkout, why not just give the orphan a branch name at those points (not sure what to do if the check is bypassed with -q, just punt I guess)? 

-Martin 


Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum

Re: Recovering Committed Changes in a Detached Head?

[Nguyen Thai Ngoc Duy]

On Sun, Oct 9, 2011 at 9:00 AM, Martin Fick <mfick@codeaurora.org> wrote:
>>git reflog to the rescue.  For your example above it will output
>>something like this:
>>
>>deadbeef HEAD@{0}: checkout: moving from
>>92aa5381b9f7229523dba42aa94735c30f173451 to New_Branch
>>  92aa5381 HEAD@{1}: commit: Committing this in the Detached Head
>>3a5bb38a HEAD@{2}: checkout: moving from master to
>>3a5bb38a83c00f7acab573f0ec836577143200aa
>>  deafbabe HEAD@{3}: ...
>>  ...
>>
>>There you see the first line of the commit message from your "lost"
>>commit, and you can do
>>
>>  git checkout -b lost_detached_head 92aa5381
>>
>>and you get a branch pointing to that commit you made while on
>>detached head, and you can work with it as usual.
>
> While rflog is cool, I can't help but think that git could be even more helpful for these scenarios.
>
> First, maybe git could create refs for these automatically, perhaps with a name like orphans/1?  Maybe these refs would only be visible via git branch --orphans.

If I remember correctly, we don't have private ref namespace, any refs
created automatically this way could be pushed out by accident.
-- 
Duy

Re: Recovering Committed Changes in a Detached Head?

[Ronan Keryell]

>>>>> On Sun, 9 Oct 2011 16:52:11 +1100, Nguyen Thai Ngoc Duy <pclouds@gmail.com> said:

    Nguyen> On Sun, Oct 9, 2011 at 9:00 AM, Martin Fick <mfick@codeaurora.org> wrote:

    >> While rflog is cool, I can't help but think that git could be
    >> even more helpful for these scenarios.

    >> First, maybe git could create refs for these automatically,
    >> perhaps with a name like orphans/1?  Maybe these refs would only
    >> be visible via git branch --orphans.

    Nguyen> If I remember correctly, we don't have private ref
    Nguyen> namespace, any refs created automatically this way could be
    Nguyen> pushed out by accident.

A way to avoid this could be to deal with this like git-stash works,
instead of relying on the branch machinery.

But anyway, I think there is a trade-off between keeping some references
to some hypothetical future use and preventing the garbage collector to
reclaim useless objects...
-- 
  Ronan KERYELL                      |\/  Phone:  +1 408 844 HPC0
  HPC Project, Inc.                  |/)  Cell:   +33 613 143 766
  5201 Great America Parkway #3241   K    Ronan.Keryell@hpc-project.com
  Santa Clara, CA 95054              |\   skype:keryell
  USA                                | \  http://hpc-project.com

Re: Recovering Committed Changes in a Detached Head?

[Matthieu Moy]

Martin Fick <mfick@codeaurora.org> writes:

>>git reflog to the rescue.  For your example above it will output
>>something like this:
>>
>>deadbeef HEAD@{0}: checkout: moving from
>>92aa5381b9f7229523dba42aa94735c30f173451 to New_Branch
>>  92aa5381 HEAD@{1}: commit: Committing this in the Detached Head
>>3a5bb38a HEAD@{2}: checkout: moving from master to
>>3a5bb38a83c00f7acab573f0ec836577143200aa
>>  deafbabe HEAD@{3}: ...
>>  ...
>>
>>There you see the first line of the commit message from your "lost"
>>commit, and you can do
>>
>>  git checkout -b lost_detached_head 92aa5381
>>
>>and you get a branch pointing to that commit you made while on
>>detached head, and you can work with it as usual.
>
> While rflog is cool, I can't help but think that git could be even more helpful for these scenarios.

Git has been showing a big scary warning when entering detached HEAD,
and now has another helpful one when leaving a commit orphan:

$ git checkout HEAD^
Note: checking out 'HEAD^'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at adcbd2f... foo

$ date > foo.txt; git add foo.txt; git commit -am "commited on detached HEAD"
[detached HEAD 9e9c4ef] commited on detached HEAD
 1 files changed, 1 insertions(+), 1 deletions(-)

$ git checkout master
Warning: you are leaving 1 commit behind, not connected to
any of your branches:

  9e9c4ef commited on detached HEAD

If you want to keep them by creating a new branch, this may be a good time
to do so with:

 git branch new_branch_name 9e9c4efeca049ca559541595c9ca4a3380dee523

Switched to branch 'master'

(since 8e2dc6ac06ae90, Junio C Hamano, Fri Feb 18 16:04:47 2011, commit:
give final warning when reattaching HEAD to leave commits behind)

I think these warnings are (scary and big) enough.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Recovering Committed Changes in a Detached Head?

[Junio C Hamano]

Martin Fick <mfick@codeaurora.org> writes:

> While rflog is cool,...
>
> First, maybe git could create refs for these automatically, perhaps with a name like orphans/1?  Maybe these refs would only be visible via git branch --orphans.

Instead of spelling them orphans/$n, you already have @{$n}.

Re: Recovering Committed Changes in a Detached Head?

[Miles Bader]

Junio C Hamano <gitster@pobox.com> writes:
>> First, maybe git could create refs for these automatically, perhaps
>> with a name like orphans/1?  Maybe these refs would only be visible
>> via git branch --orphans.
>
> Instead of spelling them orphans/$n, you already have @{$n}.

Hmm, shouldn't that be "HEAD@{$n}" (as the reflog output suggests)?

[Well, I dunno, I'm generally kind of confused by the @{...} notation,
but I just tried it out, and just @{$n} seems to refer to the current
branch, which presumably won't include the orphaned bit once one it's
been orphaned...]

Thanks,

-Miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'