It doesn't make sense to use "-m" on a mirror, since "-m"
sets up the HEAD symref in the remotes namespace, but with
mirror, we are by definition not using a remotes namespace.
Similarly, it does not make much sense to specify refspecs
with --mirror. For a mirror you plan to push to, those
refspecs will be ignored. For a mirror you are fetching
from, there is no point in mirroring, since the refspec
specifies everything you want to grab.
There is one case where "--mirror -t <X>" would be useful.
Because <X> is used as-is in the refspec, and because we
append it to to refs/, you could mirror a subset of the
hierarchy by doing:
git remote add --mirror -t 'tags/*'
But using anything besides a single branch as an argument to
"-t" is not documented and only happens to work, so closing
it off is not a serious regression.
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
builtin/remote.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index b71ecd2..2e25c6a 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -161,6 +161,11 @@ static int add(int argc, const char **argv)
if (argc < 2)
usage_with_options(builtin_remote_add_usage, options);
+ if (mirror && master)
+ die("specifying a master branch makes no sense with --mirror");
+ if (mirror && track.nr)
+ die("specifying branches to track makes no sense with --mirror");
+
name = argv[0];
url = argv[1];
--
1.7.4.2.8.g3ccd6
--
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