Daniel Barkalow [off-list ref] 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.
On Thu, 15 Oct 2009, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
$ 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*
On Thu, 15 Oct 2009, Daniel Barkalow wrote:
On Thu, 15 Oct 2009, Junio C Hamano wrote:
quoted
Daniel Barkalow [off-list ref] writes:
quoted
$ 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)
Right.
So we're back to your initial proposal I guess (storing some info/state
in .git/HEAD when detached).
Nicolas