git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Yaroslav Halchenko <yoh@onerussian.com>
To: git <git@vger.kernel.org>
Subject: [wishlist] submodule.update config
Date: Sat, 8 Dec 2018 10:45:39 -0500
Message-ID: <20181208154539.GH4633@hopa.kiewit.dartmouth.edu> (raw)

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 index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-08 15:45 Yaroslav Halchenko [this message]
2018-12-10 20:40 ` Stefan Beller
2018-12-10 22:49   ` Yaroslav Halchenko
2018-12-11  0:08     ` [PATCH] " Stefan Beller
2018-12-11  5:10       ` Yaroslav O Halchenko
2018-12-12 19:31         ` Stefan Beller
2018-12-13 16:50           ` Yaroslav Halchenko

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181208154539.GH4633@hopa.kiewit.dartmouth.edu \
    --to=yoh@onerussian.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox