# fetch --no-tags with and w/o --all

5 messages from 2013-03-06 to 2013-03-07. Participants: Cristian Tibirna, Junio C Hamano, Jeff King.
Thread: https://gitlist.dev/t/33091

## Cristian Tibirna, 2013-03-06 21:33

Subject: fetch --no-tags with and w/o --all
Message-ID: <1879950.i2j8pjGADy@gandalf>
URL: https://gitlist.dev/e/1879950.i2j8pjGADy%40gandalf

```
Hello

$ git --version
git version 1.7.10.4

$ git fetch origin --no-tags
does what it says

$ git fetch --all --no-tags
still gets all the tags from the remote.

Is this known?

Thanks.

-- 
Cristian Tibirna				(1-418-) 656-2131 / 4340
  Laval University - Quebec, CAN ... http://www.giref.ulaval.ca/~ctibirna
  Research professional at GIREF ... ctibirna@giref.ulaval.ca

```

## Junio C Hamano, 2013-03-06 21:56

Subject: Re: fetch --no-tags with and w/o --all
Message-ID: <7vboawp4zy.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vboawp4zy.fsf%40alter.siamese.dyndns.org
In-Reply-To: <1879950.i2j8pjGADy@gandalf>

```
Cristian Tibirna <ctibirna@giref.ulaval.ca> writes:

> Hello
>
> $ git --version
> git version 1.7.10.4
>
> $ git fetch origin --no-tags
> does what it says
>
> $ git fetch --all --no-tags
> still gets all the tags from the remote.
>
> Is this known?

Because --all (or --multiple) to iterate through all remotes
does not pass accept any command line refspecs, using these options
with --no-tags and/or --tags should be diagnosed as an error, but it
appears that the error checking is not done.

```

## Jeff King, 2013-03-07 00:20

Subject: Re: fetch --no-tags with and w/o --all
Message-ID: <20130307002038.GA31571@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20130307002038.GA31571%40sigill.intra.peff.net
In-Reply-To: <7vboawp4zy.fsf@alter.siamese.dyndns.org>

```
On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote:

> Cristian Tibirna <ctibirna@giref.ulaval.ca> writes:
> 
> > Hello
> >
> > $ git --version
> > git version 1.7.10.4
> >
> > $ git fetch origin --no-tags
> > does what it says
> >
> > $ git fetch --all --no-tags
> > still gets all the tags from the remote.
> >
> > Is this known?
> 
> Because --all (or --multiple) to iterate through all remotes
> does not pass accept any command line refspecs, using these options
> with --no-tags and/or --tags should be diagnosed as an error, but it
> appears that the error checking is not done.

Or we could just pass them through. Looks like this was already fixed by
8556646 (fetch --all: pass --tags/--no-tags through to each remote,
2012-09-05), which is in v1.7.12.2 and higher.

-Peff

```

## Junio C Hamano, 2013-03-07 00:41

Subject: Re: fetch --no-tags with and w/o --all
Message-ID: <7vhakonirb.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vhakonirb.fsf%40alter.siamese.dyndns.org
In-Reply-To: <20130307002038.GA31571@sigill.intra.peff.net>

```
Jeff King <peff@peff.net> writes:

> On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote:
>
>> Cristian Tibirna <ctibirna@giref.ulaval.ca> writes:
>> 
>> > Hello
>> >
>> > $ git --version
>> > git version 1.7.10.4
>> >
>> > $ git fetch origin --no-tags
>> > does what it says
>> >
>> > $ git fetch --all --no-tags
>> > still gets all the tags from the remote.
>> >
>> > Is this known?
>> 
>> Because --all (or --multiple) to iterate through all remotes
>> does not pass accept any command line refspecs, using these options
>> with --no-tags and/or --tags should be diagnosed as an error, but it
>> appears that the error checking is not done.
>
> Or we could just pass them through. Looks like this was already fixed by
> 8556646 (fetch --all: pass --tags/--no-tags through to each remote,
> 2012-09-05), which is in v1.7.12.2 and higher.

;-)  No wonder this looked somewhat familiar.

```

## Jeff King, 2013-03-07 01:08

Subject: Re: fetch --no-tags with and w/o --all
Message-ID: <20130307010829.GB850@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20130307010829.GB850%40sigill.intra.peff.net
In-Reply-To: <7vhakonirb.fsf@alter.siamese.dyndns.org>

```
On Wed, Mar 06, 2013 at 04:41:44PM -0800, Junio C Hamano wrote:

> > Or we could just pass them through. Looks like this was already fixed by
> > 8556646 (fetch --all: pass --tags/--no-tags through to each remote,
> > 2012-09-05), which is in v1.7.12.2 and higher.
> 
> ;-)  No wonder this looked somewhat familiar.

I still find it somewhat gross that we actually re-construct the
command-line from the parsed flag variables. It seems like it would be
easier to simply propagate the argv we got in the first place, and then
we would not have any chance of omitting a new option that is added
later.

Probably not worth worrying about now, though, as the fix is long since
shipped.  The next person who is adding an option can look at doing that
refactoring. And it may be that there are some options we don't
propagate intentionally (I didn't look closely).

-Peff

```