Relates (but orthogonal) to my other thread

  [wishlist] git submodule update --reset-hard

ATM, it possible to specify per submodule update strategy via
configuration variable submodule.SUBMODULE.update where SUBMODULE is the name
of the corresponding submodule.  But I see no way to specify default update
strategy for all submodules.

>From our conversation in that other thread  I have discovered to myself about
existence of  submodule.recurse  configuration, and there seems to be a few
more (.fetchJobs, .active) where e.g. .active seems to complement per-submodule
submodule.*.active:

        yoh@debian:~/proj/misc/git$ git grep '[^.]submodule\.[a-z]' -- 
Documentation/
        Documentation/RelNotes/2.14.0.txt: * Many commands learned to pay 
attention to submodule.recurse
        Documentation/RelNotes/2.15.0.txt: * "git -c submodule.recurse=yes 
pull" did not work as if the
        Documentation/config.txt:include::config/submodule.txt[]
        Documentation/config/submodule.txt:     update'. If neither 
submodule.<name>.active or submodule.active are
        Documentation/config/submodule.txt:     interact with submodules; 
settings like `submodule.active`
        Documentation/config/submodule.txt:     submodule.active config option. 
See linkgit:gitsubmodules[7] for
        Documentation/config/submodule.txt:     as computed via 
`submodule.alternateLocation`. Possible values are
        Documentation/git-clone.txt:    of multiple entries.  The resulting 
clone has `submodule.active` set to
        Documentation/git-clone.txt:    Defaults to the `submodule.fetchJobs` 
option.
        Documentation/git-submodule.txt:If no path is specified and 
submodule.active has been configured, submodules
        Documentation/git-submodule.txt:        Defaults to the 
`submodule.fetchJobs` option.
        Documentation/gitsubmodules.txt:`submodule.foo.path = path/to/bar`.
        Documentation/gitsubmodules.txt:The section `submodule.foo.*` in the 
`.gitmodules` file gives additional
        Documentation/gitsubmodules.txt:hints to Git's porcelain layer. For 
example, the `submodule.foo.url`
        Documentation/gitsubmodules.txt:  b. if the submodule's path matches 
the pathspec in `submodule.active`
        Documentation/gitsubmodules.txt:submodule's path is excluded in the 
pathspec in `submodule.active`, the
        Documentation/gitsubmodules.txt:  git config --global submodule.recurse 
true
        Documentation/gitsubmodules.txt:your working tree. Alternatively you 
can set 'submodule.recurse' to have
        Documentation/technical/api-config.txt:if 
(!git_configset_get_bool(gm_config, "submodule.frotz.ignore", &b)) {
        Documentation/technical/http-protocol.txt:  $GIT_URL:     
http://example.com/git/repo.git/path/submodule.git
        Documentation/technical/http-protocol.txt:  URL request:  
http://example.com/git/repo.git/path/submodule.git/info/refs

I wondered, if you think it would be sensible to also add of
submodule.update which would be considered before submodule.SUBMODULE.update
variable possibly defined per submodule.  That would be more inline with desire
to use any of the --merge, --rebase (and hopefully soon --reset-hard)
strategies specified as an option for submodule update, where no per-submodule
handling  is happening.

Thanks in advance for the consideration!
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

Reply via email to