Re: bug related to branches using / in name
- From
Jeff King <peff@peff.net>
- Date
- Jun 27, 2008, 03:02 UTC
- Message-ID
- <20080627030245.GA7144@sigill.intra.peff.net>
- In-Reply-To
- <1214509350.28344.31.camel@odie.local>
On Thu, Jun 26, 2008 at 09:42:30PM +0200, Simon Holm Thøgersen wrote:
Show 9 quoted lines
> 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