From: Junio C Hamano Date: Thu, 26 May 2011 17:08:48 GMT Subject: Re: [PATCH] remote: allow "-t" with fetch mirrors Message-ID: <7vk4ddxucf.fsf@alter.siamese.dyndns.org> In-Reply-To: <20110526151100.GA2881@sigill.intra.peff.net> Jeff King 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.