[PATCH] remote: allow "-t" with fetch mirrors

[PATCH] remote: allow "-t" with fetch mirrors

[Jeff King]

Commit 13fc2c1 (remote: disallow some nonsensical option
combinations, 2011-03-30) made it impossible to use "remote
add -t foo --mirror". The argument was that specifying
specific branches is useless because:

  1. Push mirrors do not want a refspec at all.

  2. The point of fetch mirroring is to use a broad refspec
     like "refs/*", but using "-t" overrides that.

Point (1) is valid; "-t" with push mirrors is useless. But
point (2) ignored another side effect of using --mirror: it
fetches the refs directly into the refs/ namespace as they
are found upstream, instead of placing them in a
separate-remote layout.

So 13fc2c1 was overly constrictive, and disallowed
reasonable specific-branch mirroring, like:

  git remote add -t heads/foo -t heads/bar --mirror=fetch

which makes the local "foo" and "bar" branches direct
mirrors of the remote, but does not fetch anything else.

This patch restores the original behavior, but only for
fetch mirrors.

Signed-off-by: Jeff King <peff@peff.net>
---
This is on top of the jk/maint-remote-mirror-safer branch which made it
into 1.7.5 (the tip of which was 0990248).

If I were designing "git remote" from scratch, I would probably have
"-t" specify branches in refs/heads, even in mirror mode, for
consistency with non-mirror mode. But making them relative to refs/ in
mirror mode is how it has always worked, and I look at this patch not as
adding a new feature but as unbreaking a feature that worked before.
So:

  git remote add -t heads/foo -t heads/bar --mirror

will continue to work as it did before the original series (though it
will nag that you should be using --mirror=fetch).

 builtin/remote.c  |    4 ++--
 t/t5505-remote.sh |   22 ++++++++++++++++++++++
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/builtin/remote.c b/builtin/remote.c
index eb1229d..c2eaa2d 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -193,8 +193,8 @@ static int add(int argc, const char **argv)
 
 	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");
+	if (mirror && !(mirror & MIRROR_FETCH) && track.nr)
+		die("specifying branches to track makes no sense with non-fetch mirrors");
 
 	name = argv[0];
 	url = argv[1];
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 4e69c90..0d0222e 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -347,6 +347,21 @@ test_expect_success 'fetch mirrors do not act as mirrors during push' '
 	)
 '
 
+test_expect_success 'add fetch mirror with specific branches' '
+	git init --bare mirror-fetch/track &&
+	(cd mirror-fetch/track &&
+	 git remote add --mirror=fetch -t heads/new parent ../parent
+	)
+'
+
+test_expect_success 'fetch mirror respects specific branches' '
+	(cd mirror-fetch/track &&
+	 git fetch parent &&
+	 git rev-parse --verify refs/heads/new &&
+	 test_must_fail git rev-parse --verify refs/heads/renamed
+	)
+'
+
 test_expect_success 'add --mirror=push' '
 	mkdir mirror-push &&
 	git init --bare mirror-push/public &&
@@ -382,6 +397,13 @@ test_expect_success 'push mirrors do not act as mirrors during fetch' '
 	)
 '
 
+test_expect_success 'push mirrors do not allow you to specify refs' '
+	git init mirror-push/track &&
+	(cd mirror-push/track &&
+	 test_must_fail git remote add --mirror=push -t new public ../public
+	)
+'
+
 test_expect_success 'add alt && prune' '
 	(mkdir alttst &&
 	 cd alttst &&
-- 
1.7.4.5.13.gd3ff5

Re: [PATCH] remote: allow "-t" with fetch mirrors

[Johannes Sixt]

Am 5/26/2011 17:11, schrieb Jeff King:
> +	if (mirror && !(mirror & MIRROR_FETCH) && track.nr)
> +		die("specifying branches to track makes no sense with non-fetch mirrors");

Don't proliferate no double negation. How about:

+		die("specifying branches to track makes sense only with fetch mirrors");

?

-- Hannes

Re: [PATCH] remote: allow "-t" with fetch mirrors

[Jeff King]

On Thu, May 26, 2011 at 05:26:14PM +0200, Johannes Sixt wrote:

> Am 5/26/2011 17:11, schrieb Jeff King:
> > +	if (mirror && !(mirror & MIRROR_FETCH) && track.nr)
> > +		die("specifying branches to track makes no sense with non-fetch mirrors");
> 
> Don't proliferate no double negation. How about:
> 
> +		die("specifying branches to track makes sense only with fetch mirrors");

I can't fail to not disagree with your logic.

Junio, can you squash it in?

-Peff

Re: [PATCH] remote: allow "-t" with fetch mirrors

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Commit 13fc2c1 (remote: disallow some nonsensical option
> combinations, 2011-03-30) made it impossible to use "remote
> add -t foo --mirror". The argument was that specifying
> specific branches is useless because:
>
>   1. Push mirrors do not want a refspec at all.
>
>   2. The point of fetch mirroring is to use a broad refspec
>      like "refs/*", but using "-t" overrides that.
>
> Point (1) is valid; "-t" with push mirrors is useless. But
> point (2) ignored another side effect of using --mirror: it
> fetches the refs directly into the refs/ namespace as they
> are found upstream, instead of placing them in a
> separate-remote layout.

Hmmm, I still fail to see the point of ignoring "mirror" aspect and
constricting that with -t.

> So 13fc2c1 was overly constrictive, and disallowed
> reasonable specific-branch mirroring, like:
>
>   git remote add -t heads/foo -t heads/bar --mirror=fetch

I mildly disagree that it is "reasonable".  I would understand if it were
something like this:

  git remote add -t heads/foo:heads/foo -t heads/bar:heads/bar

I am not saying selective copying is bad or useless.  It would be useful
in some situations.  I am saying that is not a mirror, and reusing the
same --mirror option for a different meaning may introduce confusion.

Re: [PATCH] remote: allow "-t" with fetch mirrors

[Jeff King]

On Thu, May 26, 2011 at 10:08:48AM -0700, Junio C Hamano wrote:

> > So 13fc2c1 was overly constrictive, and disallowed
> > reasonable specific-branch mirroring, like:
> >
> >   git remote add -t heads/foo -t heads/bar --mirror=fetch
> 
> I mildly disagree that it is "reasonable".  I would understand if it were
> something like this:
> 
>   git remote add -t heads/foo:heads/foo -t heads/bar:heads/bar
> 
> I am not saying selective copying is bad or useless.  It would be useful
> in some situations.  I am saying that is not a mirror, and reusing the
> same --mirror option for a different meaning may introduce confusion.

I think of it as "you are mirroring these specific refs to your
repository" instead of "you are fetching these specific refs into remote
tracking branches". But it is somewhat a matter of semantics.

I agree that allowing generalized refspecs via "-t" is a nicer solution
in the long run.  I am mostly trying to fix a regression in 13fc2c1
here; I guess the question is whether it is one worth fixing, or if
people who want to do this in the meantime should just use "git config".

-Peff