Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was

[Junio C Hamano <gitster@pobox.com>]

Christoph Bartoschek <bartoschek@gmx.de> writes:

[jc: added Daniel back to cc list; please do not cull the cc list without
good reason]

> Daniel Barkalow wrote:
>
>> The upshot of the messages should be:
>> 
>>  $ git checkout origin/master
>>  Since you can't actually change "origin/master" yourself, you'll just
>>  be sightseeing unless you create a local branch to hold new local work.
>> 
>>  $ git branch
>>  * (not a local branch, but "origin/master")
>> 
>>  $ git commit
>>  You've been sightseeing "origin/master". The commit can't change that
>>  value, so your commit isn't held in any branch. If you want to create
>>  a branch to hold it, here's how.
> ...
> But then I was not able to verify that the checkout indeed matched the 
> 1.3.0-beta.  "git status" and "git branch" did not help here. 

This is not going to help you, but "git reflog" would have helped here.

The reason my suggesting "git reflog" now won't help you is because the
word "reflog" does not connect the question "how did I get here" unless
and until you know git already; in other words, it is not your fault that
you got lost, but it is showing a wart in the UI.

If the question you were asking was "does the files I have in my work tree
after issuing that scary checkout actually match origin/1.3.0-beta?", you
could have asked that question in a more direct way, and the command to do
so is "git diff origin/1.3.0-beta".  I do not think this would be asking
the user to be doing something unreasonably unintuitive.

If the question you were asking was (and it was not, from the description
of your experience, but you could be in that situation when you "return
some weeks later") "how does the checked out history relate to 1.3.0-beta?",
then there is a way to ask the question in a very direct way, and the
command to do so is "git show-branch HEAD origin/1.3.0-beta" (or give the
same argument to "gitk").

Although it is not _so_ unreasonable to expect "git status" to show the
information, I suspect it would not be practical.  After all, whenever
somebody is lost, everything is "status".  For a person who is lost and
does not know where in the history he is, it might be reasonable to expect
"status" to give the relationship between your HEAD and some branch/tag,
while for another person who was hit by "git gui" complaining that he has
too many loose objects, it might be reasonable for him to expect "status"
to give the number of loose objects in the repository.  IOW, "status" is
too broad a word and following the path to cram everything into "status"
so that any new person who gets lost can get necessary infor from the
command will unfortunately lead to insanity.

The second item in the Daniel's transcript above may be an improvement but
I think it is a wrong economy to record and show 'but "origin/master"'
(which cannot be correct forever and has to be invalidated once the user
starts committing or resetting) in the message.  I am wondering if a
similar effect to help new users can be had by rewording the message to:

    $ git branch
    * (not a local branch; see "git reflog" to learn how you got here)

The user can see how he got there even after doing something else after
the checkout (see Nico's write-up in $gmane/130527).  The difference is
between giving fish and teaching how to catch one himself.