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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html