On Fri, Apr 28, 2017 at 12:11 PM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Thu, Apr 27, 2017 at 1:12 AM, Ævar Arnfjörð Bjarmason > <ava...@gmail.com> wrote: >> This is an expansion of the previously solo 02/05 "clone: add a >> --no-tags option to clone without tags" patch (see >> <20170418191553.15464-1-ava...@gmail.com>). >> >> 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: > >> 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: > >> Æ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 > <cacbzzx5dxajdn18j5fahjkcap8czsttrw5-escr2oq8oyyh...@mail.gmail.com> > 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.
