[PATCHv2 3/2] remote rename: warn when refspec was not updated
From: Martin von Zweigbergk <hidden>
Date: 2016-06-15 22:51:58
Subsystem:
the rest · Maintainer:
Linus Torvalds
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 <redacted> Signed-off-by: Martin von Zweigbergk <redacted> --- 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