Re: [PATCH v3 4/5] doc: be more precise on (fetch|push).recurseSubmodules

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

 



> Le 22 mars 2020 à 19:01, Junio C Hamano <gitster@xxxxxxxxx> a écrit :
> 
> Philippe Blain <levraiphilippeblain@xxxxxxxxx> writes:
> 
>>> -	This option can be either set to a boolean value or to 'on-demand'.
>>> +	This option can be set either to a boolean value or to 'on-demand'.
>>> 	Setting it to a boolean changes the behavior of fetch and pull to
>> 
>> I think in the context of patch 5 maybe it would be good to be
>> careful here, and state that this only affects the underlying
>> "fetch" in "pull", and not the whole pull ?
> 
> Meaning that sub(sub)*modules are fetched but the merge is done only
> for the top-level superproject?  I guess it does not hurt to spell
> it out.  Good suggestion.

I simply meant that since this option is 'fetch.recurseSubmodules', it applies
to the fetching operation done by 'git pull' under the hood, and not to the
 "updating the working tree" operation that is also done by git pull if 
'--recurse-submodules' is passed to it.

Regarding nested submodules, both operations would recurse down the hierarchy:
the fetching fetches all (nested) populated submodules because of the call to 
submodule.c::fetch_populated_submodules near the end of builtin/fetch.c::cmd_fetch 
and the "updating the working tree", which is controlled 
by the '--recurse-submodules' flag of 'git pull',  updates all active submodules  
because it spawns 'git submodule update --recursive', (as per rebase_submodules
and update_submodules in builtin/pull.c).



[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]

  Powered by Linux