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

Julian Phillips <julian@quantumfyre.co.uk> writes:

Sorry, but I do not see in what way what you said in the thread connects to the above three lines. Are you talking about this one from you a few messages back?

    How about:

    $ git checkout origin/master
    $ git fetch
    Refusing to fetch, as it would update a checkedout branch
    "git fetch -f" will force the update, but you will need to run "git
    reset --hard HEAD" to update your checkout to match.

I am not seeing "not the implementation ease but the user experience" drive in this suggestion. If you are driving from the user experience point of view, I would have instead suggested:

    How about:

    $ git checkout origin/master
    $ git fetch

    and fetch happily updates the tracked branch, without affecting the
    HEAD state (nor index nor the work tree, of course).

User experience here is:

    * Let's checkout what the upstream has on the master.  I am at least
      aware that git is distributed and does not go to the network unless
      I tell it to, and am aware that origin/master is the state of the
      upsream _when I told git to look at it the last time_.  So I'll get
      the state I talked with the upstream the last time, and that is what
      I want to look at.

    * Hmm, there may be even more updates since I talked with the upstream
      the last time.  Let's tell git to fetch.  I already know that this
      updates origin/master to a more recent state.

Isn't it much cleaner and less confusing? And with these kind of awareness, the user can choose to do various things from here, e.g.:

    * Oh, fetch did fetched something.  I want the updated state.  Let's
      check it out with "git checkout origin/master"; or

    * Ok, what changed since I last talked with the upstream?  I have one
      end of the state already checked out, and I updated origin/master
      with their latest, so I can say "git diff HEAD origin/master".

Notice in the latter the user can be a neophyte who hasn't learned reflogs yet.

Hmm, what is lacking in "git describe HEAD" for that? I am not complaining that you might be asking for something that exists, but I _do_ want to know if something that exists is not a satisfactory solution and if so how it can be improved.