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

[James Pickens <jepicken@gmail.com>]

On Thu, Oct 15, 2009 at 3:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>     $ git checkout origin/next ;# ditto
>>     $ git symbolic-ref HEAD
>>     refs/remotes/origin/next
>
> Ok, after reading Daniel's message to remind us that "git fetch" after
> this will get us into trouble, I agree that detaching HEAD is inevitable.

Some people liked the idea, so let's not give up just yet.  Here are a few
things Git could do when a fetch wants to update the currently checked out
branch:

1. Refuse the fetch.
2. Update the ref, leaving the user with a work tree and index that don't
   match their HEAD.
3. Detach the HEAD, then update the ref.
4. Update the ref, then check it out.

Option 1 is ok, as long as the "next step" is not too complicated.  It's no
good if the user has to checkout a different branch, then fetch, then
checkout the original branch again.

Option 2 is crap.

Option 3 seems reasonable, but it might be just as scary/confusing to
newbies as the current behavior, so I don't think it should be the default.

Option 4 also seems reasonable, but you run into problems if the user had
changed the index or work tree.  In that case Git could do 'checkout
--merge' automatically.  This option is also less "pure" since it lets 'git
fetch' modify the index and work tree.

So how about this:
* 'git fetch' refuses the fetch by default.
* 'git fetch --detach' detaches HEAD, then updates the ref
* 'git pull' detaches HEAD, updates the ref, then checks out the new ref
  with --merge.

BTW I'm not convinced this is any better than the current UI... just
thinking out loud.  And I find it more than a little depressing that most
of these ideas have already been discussed almost 3 years ago (thanks Jeff
for the pointer).

James