Re: master^ is not a local branch -- huh?!?

["Octavio Alvarez" <alvarezp@alvarezp.ods.org>]

On Fri, 29 Jan 2010 13:34:01 -0800, Ron Garret <ron1@flownet.com> wrote:

> In article <op.u7a909hf4oyyg1@alvarezp-ws>,
>  "Octavio Alvarez" <alvarezp@alvarezp.ods.org> wrote:
>
>> On Fri, 29 Jan 2010 12:20:46 -0800, Ron1 <ron1@flownet.com> wrote:
>>
>> It means that if you switch to master^ and commit, your commit will
>> be applied but not tracked (since there is not any branch to advance).
>>
>> You would need to do git checkout -b 'new_branch', and then commit.
>> Now, new_branch will advance with your new commit.
>
> OK, I think I understand that.
>
> Here's the thing: I can do this:
>
> git checkout commit-id filename
>
> and restore a particular revision of a particular file to my working
> tree without affecting my HEAD pointer.  I would expect then that
>
> git checkout commit-id
>
> with no filename would do the same thing, except restore the entire tree
> from that commit (including deleting files that didnt' exist then).  And
> indeed it does that (or at least appears to -- I haven't explored this
> in depth), except that it DOES move my HEAD pointer to this weird
> non-branch thing.

I see. You somehow imply that "git checkout commit-id" overlaps with
"git reset --hard commit-id".

Even assuming the behavior was not documented in man git-checkout, the
second example looks useless. What is your use case? What would you do
after having all the files in the tree switched to another commit,
without actually updating HEAD to the commit, other than git reset --hard
again or git revert?