From: Jens Lehmann <Jens.Lehmann@web.de>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>,
Kevin Ballard <kevin@sb.org>, Jon Seymour <jon.seymour@gmail.com>,
Chris Packham <judge.packham@gmail.com>,
Marc Branchaud <marcnarc@xiplink.com>
Subject: Re: [PATCH v3 2/3] Add the 'fetch.recurseSubmodules' config setting
Date: Fri, 12 Nov 2010 12:40:38 +0100 [thread overview]
Message-ID: <4CDD27B6.3070907@web.de> (raw)
In-Reply-To: <7v1v6rhfut.fsf@alter.siamese.dyndns.org>
Am 11.11.2010 19:31, schrieb Junio C Hamano:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>> "fetch.recurseSubmodules" is only read from .git/config. The one read
>>> first from .gitmodules and then from .git/config is the per-submodule
>>> setting "submodule.<name>.fetchRecurseSubmodules" added in 3/3.
>>
>> Sorry for the nonsense. Would it be easy (or desirable) to make
>> _that_ one not be read from .gitmodules?
>
> I think the motivation behind having a way to read it from .gitmodules is
> so that project can suggest the default for convenience (e.g. "almost
> everybody who interacts with this project wants these submodules checked
> out and kept updated").
Yes, and to achieve that it should /not/ be necessary to run a "git
submodule sync" manually afterwards to activate those changes.
Jonathan, I think when we allow upstream to configure which submodules
are to be cloned and checked out by default (which seems an option almost
everyone likes to have), doesn't it make sense to let upstream set a
default which submodules should be fetched too (so that new commits there
can be checked out recursively later)? I would rather not like to do that
implicitly just because a submodule is configured for recursive checkout
...
> Traditionally the suggestions kept in .gitmodules were propagated to the
> config when the submodule was initialized, and at runtime we read only
> from the config from then on without reading from .gitmodules, so that
> once the user decides to follow what the project suggests (or customize
> that away), the preference would stick to the repository.
>
> That arrangement does not cater well to people who want to follow along
> whatever the project's suggestion of the day, so we might want to change
> things so that we if we find it in the config, we stop there and use what
> we found, otherwise we use what is in the in-tree gitmodules; I suspect we
> might require some changes to "submodule init" not to copy certain things
> to the config for that to work, though...
Right. But this would enable you to have branches where different sets
of submodules are fetched, checked out and/or considered to make the
superproject dirty depending on the topic the branch is for.
next prev parent reply other threads:[~2010-11-12 11:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-10 23:53 [PATCH v3 0/3] Teach fetch and pull to recursively fetch submodules Jens Lehmann
2010-11-10 23:54 ` [PATCH v3 1/3] fetch/pull: Add the --recurse-submodules option Jens Lehmann
2010-11-10 23:55 ` [PATCH v3 2/3] Add the 'fetch.recurseSubmodules' config setting Jens Lehmann
2010-11-11 0:02 ` Jonathan Nieder
2010-11-11 8:14 ` Jens Lehmann
2010-11-11 8:27 ` Jonathan Nieder
2010-11-11 18:31 ` Junio C Hamano
2010-11-11 19:00 ` Jonathan Nieder
2010-11-12 11:54 ` Jens Lehmann
2010-11-12 15:52 ` Jonathan Nieder
2010-11-12 19:48 ` Jens Lehmann
2010-11-12 20:16 ` Jonathan Nieder
2010-11-12 21:58 ` Jens Lehmann
2010-11-12 11:40 ` Jens Lehmann [this message]
2010-11-10 23:55 ` [PATCH v3 3/3] Submodules: Add the "fetchRecurseSubmodules" config option Jens Lehmann
2010-11-11 0:05 ` [PATCH v3 0/3] Teach fetch and pull to recursively fetch submodules Jonathan Nieder
2010-11-11 8:18 ` Jens Lehmann
2010-11-12 12:54 ` [PATCH v4 1/3] fetch/pull: Add the --recurse-submodules option Jens Lehmann
2010-11-12 19:54 ` Jonathan Nieder
2010-11-12 20:22 ` Jens Lehmann
2010-12-09 21:16 ` Junio C Hamano
2010-12-09 23:07 ` Jens Lehmann
2010-12-10 17:30 ` Junio C Hamano
2010-12-10 18:03 ` Jens Lehmann
Reply instructions:
You may reply publicly 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CDD27B6.3070907@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jon.seymour@gmail.com \
--cc=jrnieder@gmail.com \
--cc=judge.packham@gmail.com \
--cc=kevin@sb.org \
--cc=marcnarc@xiplink.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).