On Thu, Sep 01, 2011 at 08:35:01PM -0400, Martin von Zweigbergk wrote: > > 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. Yeah, I think with the change in patch 1, your patch 2 is very reasonable. It is admitting that "git remote" is really about tweaking the default remote config, and punting on config that doesn't appear to follow it. And doing it consistently. I don't think there's nothing wrong with that. -Peff -- 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