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

> On 2009.10.16 18:31:23 +0100, Julian Phillips wrote:
>> On Fri, 16 Oct 2009, Bj?rn Steinbrink wrote:
>>> On 2009.10.16 13:15:35 +0100, Julian Phillips wrote:
>>>> 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.
>>>
>>> That would redefine -f (currently means "allow non-fast-forward
>>> updates"), the flag that allows the checked out branch head to be
>>> updated is -u, --update-head-ok, and is for internal use only.
>>>
>>> And suggesting "reset --hard" seems wrong, that just kills any
>>> uncommitted changes.
>>
>> Ok, so the commands were wrong.  Not important.
>>
>> It was the approach that I was trying to suggest rather than the
>> actual commands.  The point I was trying to make was how, as a user,
>> I would be happy to git behave.
>
> Your approach explicitly included "mess up the index/worktree state",
> otherwise, "git fetch" would not have to tell the user that he has to do
> a "git reset --hard HEAD". I honestly can't believe that you would be
> happy with git messing up your work.
>
>> So, I try to run fetch, git says "ooh, now that would be dangerous -
>> you can force it happen by running "git foo", but you will then be
>> in situation X, which you can then recover from by running "git
>> bar", though you may need to run "git stash" to save any edits you
>> have made" or something similar.
>
> But why make "git fetch" with non-"obscure" refspecs dangerous to begin
> with? If we detach but keep some extra information, there's no need to
> make "git fetch" dangerous, _and_ we can still provide a command that
> just fetches the most recent version of the "checked out" remote
> tracking branch and checks that out. May it be another mode of operation
> for "git pull" or some "git up" command or whatever.