git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>,
	Chris Packham <judge.packham@gmail.com>
Cc: git@vger.kernel.org, mara.kim@vanderbilt.edu,
	Jonathan Nieder <jrnieder@gmail.com>,
	Heiko Voigt <hvoigt@hvoigt.net>
Subject: Re: [RFC PATCH] clone: add clone.recursesubmodules config option
Date: Wed, 04 Jun 2014 21:06:58 +0200	[thread overview]
Message-ID: <538F6E52.9000009@web.de> (raw)
In-Reply-To: <xmqqvbsgvb9l.fsf@gitster.dls.corp.google.com>

Am 04.06.2014 19:24, schrieb Junio C Hamano:
> Chris Packham <judge.packham@gmail.com> writes:
> 
>> On 04/06/14 09:05, Junio C Hamano wrote:
>>>> Also, going --recursive when the user did not want is a lot more
>>>> expensive mistake to fix than not being --recursive when the user
>>>> wanted to.
>>>
>>> Having said all that, I do not mean to say that I am opposed to
>>> introduce some mechanism to let the users express their preference
>>> between recursive and non-recursive better, so that "git clone"
>>> without an explicit --recursive (or --no-recursive) can work to
>>> their taste.  A configuration in $HOME/.gitconfig might be a place
>>> to start, even though that has the downside of assuming that the
>>> given user would want to use the same settings for all his projects,
>>> which may not be the case in practice.
>>
>> And here's a quick proof of concept. Not sure about the config variable name
>> and it could probably do with a negative test as well.
> 
> I would be more worried about the semantics than the name, though;
> re-read the part you quoted with extra stress on "has the downside".
> 
> I think I heard the submodule folks (cc'ed) discuss an approach to
> allow various submodules to be marked with "tags" with a new type of
> entry in .gitmodules file in the superproject, and use these tags to
> signal "by default, a new clone will recurse into this submodule".
> 
> E.g. if projects standardized on "defaultClone" to mark such
> submodules, then $HOME/.gitconfig could say
> 
>     [clone]
>         recursesubmodules = defaultClone
> 
> Or the projects may mark platform specific submodules with tags,
> e.g. a .gitmodules in a typical superproject might say something
> like this:
> 
>     [submodule "posix"]
>     	path = ports/posix
>         tags = linux obsd fbsd osx
>     [submodule "windows"]
>         path = ports/windows
>         tags = win32
>     [submodule "doc"]
>     	path = documentation
>         tags = defaultClone
> 
> and then the user's $HOME/.gitconfig might say
> 
>     [clone]
>         recursesubmodules = defaultClone win32
> 
> to tell a "git clone" of such a superproject to clone the top-level,
> read its .gitmodules, and choose documentation/ and ports/windows
> submodules but not ports/posix submodule to be further cloned into
> the working tree of the superproject.
> 
> Of course, if this kind of project organization proves to be useful,
> we should try to standardize the set of tags early before people
> start coming up with random variations of the same thing, spelling
> the same concept in different ways only to be different, and if that
> happens, then we could even give a non-empty default value for the
> clone.recursesubmodules when $HOME/.gitconfig is missing one.

Yes, but maybe we can define how the user wants to set the global or
per-repo default (that is honored as long as upstream or local
config doesn't provide more specific settings, e.g. via tags) and
implement that for clone as a first step, even when we do not now
how e.g. the tags setting might look like in the end. I believe we
should have one or two switches telling Git "I want my submodules be
updated without having to use the 'git submodule' command". And
after that submodule specific overrides can kick in, e.g. when
"submodule.<name>.update" is set to "none" the submodule won't be
updated no matter how the default is.

We had two settings in mind, first "submodule.autoinit" (which would
automate the "git submodule --init" step and also control that a
new submodule is fetched into .git/modules; it'd be fetched there
soon as the fetch in the superproject sees a commit introducing it).
That would kick in on clone, fetch and pull, as the underlying fetch
honors it. And the "submodule.autoupdate" setting which will make
running "git submodule update" obsolete by updating all init'ed
submodules on each clone, checkout, merge, reset etc.. Together
they'd achieve for all relevant commands what Chris' proposed option
would only do for clone.

So what if clone would just do an "git submodule init" for now when
"submodule.autoinit" is set but "submodule.autoupdate" isn't (and as
soon as fetch learns to honor autoinit we could remove that one
again). And if both are set it'd do a "git submodule update --init
--recursive", just like it does when the --recurse-submodules option
is used. As soon as we also have recursive submodule update, we could
remove the latter from clone.

But maybe we are to close to the implementation side of things (where
fetch and checkout just like init and update are two separate things)
and a single "submodule.auto" setting would be what users really want?

Comments welcome.

  reply	other threads:[~2014-06-04 19:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 18:11 Paper cut bug: Why isn't "git clone xxxx" recursive by default? Mara Kim
2014-06-03 19:52 ` Junio C Hamano
2014-06-03 21:05   ` Junio C Hamano
2014-06-03 22:24     ` Mara Kim
2014-06-04  9:30     ` [RFC PATCH] clone: add clone.recursesubmodules config option Chris Packham
2014-06-04 17:24       ` Junio C Hamano
2014-06-04 19:06         ` Jens Lehmann [this message]
2014-06-05 18:18           ` Junio C Hamano
2014-06-05 18:43             ` W. Trevor King
2014-06-06  5:26             ` Heiko Voigt
2017-08-02 18:11               ` Jeremy Morton
2017-08-02 20:34                 ` Stefan Beller
2014-06-04 19:42         ` Heiko Voigt
2014-06-05  7:48           ` Chris Packham
2014-06-06  5:54             ` Heiko Voigt
2014-06-06 16:35               ` Junio C Hamano
2014-06-09 13:17               ` Jens Lehmann
2014-06-09 23:27                 ` W. Trevor King
2016-10-03 15:36       ` Jeremy Morton
2016-10-03 17:18         ` Stefan Beller
2016-10-04 11:41           ` Heiko Voigt

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

  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=538F6E52.9000009@web.de \
    --to=jens.lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hvoigt@hvoigt.net \
    --cc=jrnieder@gmail.com \
    --cc=judge.packham@gmail.com \
    --cc=mara.kim@vanderbilt.edu \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).