On Thu, Oct 15, 2009 at 3:08 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html