Jeff King wrote:
quoted text
> Jeff King wrote:
> 
> > 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.
> 
Your summary is correct, but I cannot entirely convince myself that
leaving old branches available is valid in any work flow. But what do I
know.

quoted text
> BTW, you can get the opposite problem, too. If you have
> "refs/remotes/origin/foo/bar", and then the remote removes "foo/bar" in
> favor of "foo", you will have a conflict on fetch.
> 
Yes, and you can also hit a similar problem using git-push, but I guess
that the user is a bit more aware about what is going on in that case
and is able resolve the problem without hints.

I tested the two patches and they did indeed seem to do what you
intended them to for my test case. The solution is not exactly pretty,
but it is better than nothing and it is admittedly a corner case.

Thank you for your time on this Jeff.


Simon Holm Thøgersen

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html