Re: bug related to branches using / in name

From: Simon Holm Thøgersen <odie@cs.aau.dk>
Date: Jun 27, 2008, 08:32 UTC
Message-ID: <1214555532.10090.18.camel@odie.local>
In-Reply-To: <20080627030422.GB7144@sigill.intra.peff.net>

Jeff King wrote:

Show 12 quoted lines

> 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.

> 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