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

Jeff King [off-list ref] 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.

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

quoted

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