Re: [PATCH 2/2] remote: "rename o foo" should not rename ref "origin/bar"

From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Sep 2, 2011, 00:35 UTC
Message-ID: <alpine.DEB.2.00.1109012022110.7267@debian>
In-Reply-To: <20110901024617.GD31838@sigill.intra.peff.net>

On Wed, 31 Aug 2011, Jeff King wrote:

Show 11 quoted lines

> On Wed, Aug 31, 2011 at 09:50:43PM -0400, Martin von Zweigbergk wrote:
> 
> > When renaming a remote called 'o' using 'git remote rename o foo', git
> > should also rename any remote-tracking branches for the remote. This
> > does happen, but any remote-tracking branches starting with
> > 'refs/remotes/o', such as 'refs/remotes/origin/bar', will also be
> > renamed (to 'refs/remotes/foorigin/bar' in this case).
> 
> To be totally correct, shouldn't this check each ref against the RHS of
> the remote's old refspec, and rename it according to the remote's new
> refspec?

That's what I thought too, but was planning on leaving it for a separate patch. However, after changing patch 1 to only update the fetch refspecs from "refs/remotes/$OLD" to "refs/remotes/$NEW", there is no other place in the fetchspec where a remote name can occur and 'git remote rename' still understands it. So since we're now being more conservative about updating refspecs, I guess we need to be equally conservative about updating ref names.

Martin