Re: [PATCH v3 4/5] clone: add a --no-tags-submodules to pass --no-tags to submodules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/26, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason  <avarab@xxxxxxxxx> writes:
> 
> > From: Brandon Williams <bmwill@xxxxxxxxxx>
> >
> > Add a --no-tags-submodules which does for --no-tags what the existing
> > --shallow-submodules does for --depth, i.e. doing:
> >
> >     git clone --recurse-submodules --no-tags --no-tags-submodules <url>
> >
> > Will clone the superproject and all submodules with --no-tags
> > semantics.
> >
> > This change does not implement a submodule.*.tags config .gitmodules
> > configuration option corresponding to the existing submodule.*.shallow
> > facility, which would make --no-tags have full feature parity with
> > --shallow-submodules.
> 
> Shouldn't --no-tags automatically propagate down to submodules in
> --recurse-submodules mode instead?  I know --shallow-submodules
> exists but it looks to me more a misdesigned interface, rather than
> something we want to mimic in a new option.

I agree, I would think that the --no-tags option should be propagated
down when --recurse-submodules is provided, without needed to provide
another option for that.  Thinking about the recursive case here
(submodules in side of submodules) you would then need to propagate down
two options, --no-tags and --no-tags-submodules, which feels a bit
awkward.

> The design of the traditional "git submodule" support strived to
> keep the superproject and its submodules distinct and separately
> managed as much as possible, and I view the motivation behind the
> recent push of "--recurse-submodules" as an attempt to make them
> appear as seamless as possible, so I have a feeling that a new
> option (like "--no-tags") that is applied to the superproject, as
> long as it also makes sense to use it in submodules, should
> propagate down in that mode by default (and most likely
> unconditionally).  Those who want finer granularity of control can
> use the traditional "work with superproject, and then initialize and
> update the submodules you are interested in in any way you want
> individually" mode anyway.
> 
> > Signed-off-by: Brandon Williams <bmwill@xxxxxxxxxx>
> > Code-by: Brandon Williams <bmwill@xxxxxxxxxx>
> > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
> > Commit-message-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
> > Git-Completion-Code-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
> > Docs-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
> > Tests-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
> 
> Is it just me who finds this way of attribution unwieldy?  I would
> have expected to see something like this at the end
> 
> 	The main code is by Brandon, Ævar added the docs, tests and
> 	completion and wrapped them up into a commit with a log
> 	message.
> 
> before two s-o-b.

Yeah this looks a bit messy.  Ævar, you've spent much longer on this
topic than I have and should probably take authorship.  I mean I only
spent a little bit cobbling together a patch that I never tested. :)
You're more than welcome to include my 'Signed-off-by' and/or a
'Helped-by' line for this patch though.

-- 
Brandon Williams



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]