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?
Maybe that is just being pedantic, though. This should work fine with
the default config[1].
-Peff
[1] Since this part of the renaming process obviously depends heavily on
refs/remotes/$OLD being the naming convention, shouldn't the
renaming of the refspecs do the same thing? I.e., it's another
reason that your patch 1/2 should only tweak refs/remotes/$OLD.
Otherwise you will get renamed refspecs, but the actual refs won't
be moved.
--
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