Re: [PATCH v3 0/5] clone: --no-tags option

On Fri, Apr 28, 2017 at 12:11 PM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:

On Thu, Apr 27, 2017 at 1:12 AM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:

quoted

This is an expansion of the previously solo 02/05 "clone: add a
--no-tags option to clone without tags" patch (see
[ref]).

This addresses the comments by Junio & Jonathan Nieder on v2 (thanks a
lot), and in addition implements a --no-tags-submodules option. That
code was implemented by Brandon & sent to me privately after I'd
failed to come up with it, but I added tests, a commit message & bash
completion to it.

The WIP 5/5 patch implements a submodule.NAME.tags config facility for
the option, but is broken currently & floats along in this submission
as an RFC patch. AFAICT it *should* work and it goes through all the
motions the similar existing *.shallow config does, but for some
reason the tags=false option isn't picked up & propagated in a freshly
cloned submodule.

I'm probably missing something trivial, but I can't see what it is,
I'm hoping thath either Stefan or Brandon will see what that is.

Junio, can you please just take patch 1-3 in this series, i.e.:

DROP:

quoted

Brandon Williams (1):
  clone: add a --no-tags-submodules to pass --no-tags to submodules
[...]
  WIP clone: add a --[no-]recommend-tags & submodule.NAME.tags config

KEEP:

quoted

Ævar Arnfjörð Bjarmason (4):
  tests: change "cd ... && git fetch" to "cd &&\n\tgit fetch"
  clone: add a --no-tags option to clone without tags
  tests: rename a test having to do with shallow submodules

I think a fair summary of the discussion so far is that the submodule
interaction I copy/pasted from --shallow-submodules isn't how we want
to do things at all, I defer to Stefan & Brandon on that.

ok. In that case we'd want to discuss what we actually want with no-tags
in submodules.

The only other objection to the patches marked as KEEP is from Stefan
saying it should be --tags on by default not --no-tags off by default.
As noted in [ref]
I don't disagree, but a lot of flags in git now use that pattern, and
this change is consistent with those. Makes sense to discuss changing
that as another series.

Ok. I assumed with that next series on the radar, we'd not want to intentionally
add more of the no-OPTIONs as that would produce more work for that series.