From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Fri, 02 Sep 2011 00:35:01 GMT
Subject: Re: [PATCH 2/2] remote: "rename o foo" should not rename ref "origin/bar"
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:

> 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