[PATCH 1/3] remote: disallow some nonsensical option combinations
- From
Jeff King <peff@peff.net>
- Date
- Mar 30, 2011, 19:52 UTC
- Message-ID
- <20110330195252.GA30624@sigill.intra.peff.net>
- In-Reply-To
- <20110330195139.GA814@sigill.intra.peff.net>
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@peff.net> --- 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