When renaming a remote, we also try to update the fetch refspec
accordingly, but only if it has the default format. For others, such
as refs/heads/master:refs/heads/origin, we are conservative and leave
it untouched. Let's give the user a warning about refspecs that are
not updated, so he can manually update the config if necessary.
Suggested-by: Jeff King <peff@xxxxxxxx>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx>
---
This addresses the first part of your email. I'm not sure what should
happen when only some refspecs can be updated. I can't think of any
sensible examples with mixed default and non-default refspecs, so for
me it's hard to see whether we would make things better or worse by
making it all-or-nothing. I have more or less always used the default
ones myself. Do you have any good examples?
builtin/remote.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 0df6ab0..61326cb 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -672,6 +672,12 @@ static int mv(int argc, const char **argv)
ptr-buf2.buf + strlen(":refs/remotes/"),
strlen(rename.old), rename.new,
strlen(rename.new));
+ else
+ warning("Not updating non-default fetch respec\n"
+ "\t%s\n"
+ "\tPlease update the configuration manually if necessary.",
+ buf2.buf);
+
if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
return error("Could not append '%s'", buf.buf);
}
--
1.7.6.51.g07e0e
--
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