On Thu, 15 Oct 2009, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > > > $ git checkout origin/master > > $ git fetch > > $ git checkout origin/next > > Uncommited file '...' would be overwritten. > > > > If HEAD is a symref to refs/remotes/origin/master, and you update > > refs/remotes/origin/master, git will subsequently see that your index > > doesn't match HEAD, and when you switch branches, it will try to apply a > > revert to the branch you're switching to. It's the same issue as pushing > > into a non-bare repository. > > I think the idea here is to allow HEAD to point at outside refs/heads/, > e.g. refs/remotes/origin/master, but forbid commit and other commands from > updating HEAD and its underlying ref via update_ref() unless HEAD is > detached or points at a local branch. $ git checkout origin/master $ git fetch (Some error) I think it would be much more confusing for many users if you couldn't do: $ git checkout origin/master (look at origin/master) (wait a day) $ git fetch $ git checkout origin/next (look at origin/next) Part of the original point of detached HEAD was to support this pattern without creating an undesired local branch (which falls out of date), having problems with updating the tracking branches, or having problems with direct changes to the ref that HEAD points to. Currently, HEAD is never a symref to anything that will ever be updated normally except though the symref. That's a really handy property that avoids making us deal with lots of special cases in weird places. And those special cases would not only be annoying to have to handle again, but they'd be complexity that users would have to be exposed to. -Daniel *This .sig left intentionally blank* -- 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