On Thu, Jun 26, 2008 at 09:42:30PM +0200, Simon Holm Thøgersen wrote: > The last command does not succeed, but produces the following output > > error: unable to resolve reference refs/remotes/origin/sched/devel: Not > a directory > >From file:///tmp/git-bug > * [new branch] sched/devel -> origin/sched/devel > error: unable to resolve reference refs/remotes/origin/sched/urgent: Not > a directory > * [new branch] sched/urgent -> origin/sched/urgent So to summarize, the problem is that you have an old tracking branch "refs/remotes/sched" that exists on the client, but upstream has since removed it in favor of "sched/devel", which you are now trying to fetch. And of course there is a conflict, because of the ref naming rules. This doesn't work seamlessly because git-fetch never removes old tracking branches, even if they have been deleted upstream. And normally there is no conflict; leaving the old branches means they don't disappear from under you. In this case, of course, it's inconvenient. The "right" way to solve it is to tell git to clean up your tracking branches for "origin": git remote prune origin which should delete the old "sched" tracking branch (since it no longer exists on the remote), and then you are free to fetch. It might be nicer if this were handled automatically, but it would violate git-fetch's rule about never deleting branches. And presumably this comes up infrequently enough that it isn't a problem. Perhaps a better error message suggesting git-prune might make sense? -Peff -- 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
