All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mahi Kolla <mahikolla@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Mahi Kolla via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	Philippe Blain <levraiphilippeblain@gmail.com>
Subject: Re: [PATCH v4] clone: update submodule.recurse in config when using --recurse-submodule
Date: Tue, 10 Aug 2021 00:26:01 -0700	[thread overview]
Message-ID: <CAN3QUFYPjsvBRGegO-kC7+gcFDczOqQSw-UYphnLHx=6-6kkwA@mail.gmail.com> (raw)
In-Reply-To: <xmqqzgtqe2w6.fsf@gitster.g>

Hi Junio,

Thank you for your feedback!

On Mon, Aug 9, 2021 at 2:15 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Mahi Kolla via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Mahi Kolla <mahikolla@google.com>
> >
> > When running 'git clone --recurse-submodules', developers might expect various other commands such as 'pull' and 'checkout' to also run recursively into submodules. Set 'submodule.recurse' to true when 'git clone' is run with '--recurse-submodules'.
>
> Please wrap overlong lines in your proposed log message to say 70 or
> so columns.
>

Ah, my bad, will do so going forward.

> Some developers might expect, but wouldn't some others want to see
> this not set to true, but want to recurse only into some but not all
> submodules?
>

I definitely agree with this. Currently, the `--recurse-submodules`
option takes in 1 parameter, a pathspec to the submodule they would
like to initialize. `submodule.active` stores this path or `.` if no
path is specified. Accordingly, `submodule.recurse=true` will only
apply to the submodules specified by the user in `submodule.active`.
This way users can ensure commands are run recursively only in
submodules they have listed as active.


> Is it possible to avoid changing the behaviour unconditionally and
> potentially breaking existing users by making it an opt-in feature,
> e.g. "git clone --recurse-submodules" would work as the current
> users would expect, while "git clone --recurse-submodules=sticky"
> would set submodule.recurse to true, or something?

As mentioned, the `submodule.recurse=true` will only apply to active
submodules specified by the user. Setting this config value when the
user runs their initial `git clone` minimizes the number of times a
developer must use the `--recurse-submodule` option on other commands.

However, this is a behavior change that may be surprising for
developers. To ensure a smooth rollout and easy adoption, I think
adding a message using an `advice.*` config setting would be useful.
When a user runs `git clone --recurse-submodules` an advice message
will pop up alerting them `submodule.recurse=true`, what this means
for other commands' functionality, and how to change it back (`git -C
dst-dir config submodule.recurse false`). This also gives the user the
option to turn off the advice message if they don't need it.

I'll also update the appropriate documentation to better explain how
setting submodule.recurse=true effects workflow.

Let me know what you think!

Best,
Mahi Kolla

  reply	other threads:[~2021-08-10  7:26 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 17:29 [PATCH 0/2] clone: update submodule.recurse in config when using --recurse-submodule Mahi Kolla via GitGitGadget
2021-08-02 17:29 ` [PATCH 1/2] " Mahi Kolla via GitGitGadget
2021-08-02 17:29 ` [PATCH 2/2] " Mahi Kolla via GitGitGadget
2021-08-02 22:38 ` [PATCH v2 0/3] " Mahi Kolla via GitGitGadget
2021-08-02 22:38   ` [PATCH v2 1/3] " Mahi Kolla via GitGitGadget
2021-08-02 22:38   ` [PATCH v2 2/3] " Mahi Kolla via GitGitGadget
2021-08-02 22:38   ` [PATCH v2 3/3] clone test: update whitespace according to style guide Mahi Kolla via GitGitGadget
2021-08-02 23:23   ` [PATCH v3 0/4] clone: update submodule.recurse in config when using --recurse-submodule Mahi Kolla via GitGitGadget
2021-08-02 23:23     ` [PATCH v3 1/4] " Mahi Kolla via GitGitGadget
2021-08-03  3:20       ` Philippe Blain
2021-08-07  3:06         ` Mahi Kolla
2021-08-02 23:23     ` [PATCH v3 2/4] " Mahi Kolla via GitGitGadget
2021-08-02 23:23     ` [PATCH v3 3/4] clone test: update whitespace according to style guide Mahi Kolla via GitGitGadget
2021-08-02 23:23     ` [PATCH v3 4/4] clone: " Mahi Kolla via GitGitGadget
2021-08-03  3:08     ` [PATCH v3 0/4] clone: update submodule.recurse in config when using --recurse-submodule Philippe Blain
2021-08-03 22:41     ` Junio C Hamano
2021-08-09 19:11     ` [PATCH v4] " Mahi Kolla via GitGitGadget
2021-08-09 21:15       ` Junio C Hamano
2021-08-10  7:26         ` Mahi Kolla [this message]
2021-08-10 18:36           ` Junio C Hamano
2021-08-10 23:04             ` Philippe Blain
2021-08-10 23:59               ` Mahi Kolla
2021-08-11  5:02             ` Junio C Hamano
2021-08-12  2:46       ` [PATCH v5] clone: set submodule.recurse=true if user enables feature.experimental flag Mahi Kolla via GitGitGadget
2021-08-12  4:20         ` Junio C Hamano
2021-08-12 23:54           ` Emily Shaffer
2021-08-13  3:35             ` Philippe Blain
2021-08-13  4:12               ` Mahi Kolla
2021-08-13 19:53                 ` Junio C Hamano
2021-08-13 14:59               ` Junio C Hamano
2021-08-13  4:34             ` Junio C Hamano
2021-08-13 20:23               ` Emily Shaffer
2021-08-13 20:30                 ` Junio C Hamano
2021-08-13 20:38                   ` Emily Shaffer
2021-08-13 20:48                     ` Mahi Kolla
2021-08-13 20:52                 ` Junio C Hamano
2021-08-13 17:33         ` Felipe Contreras
2021-08-14  1:09         ` [PATCH v6] clone: set submodule.recurse=true if submodule.stickyRecursiveClone enabled Mahi Kolla via GitGitGadget
2021-08-14 18:05           ` Junio C Hamano
2021-08-17 23:02             ` Emily Shaffer
2021-08-18 19:57               ` Junio C Hamano
2021-08-18 20:15                 ` [PATCH] fixup! " Junio C Hamano
2021-08-19 17:41                   ` Emily Shaffer
2021-08-30 20:59                     ` Emily Shaffer
2021-08-30 21:23                       ` Junio C Hamano
2021-08-18 22:40           ` [PATCH v6] " Philippe Blain

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='CAN3QUFYPjsvBRGegO-kC7+gcFDczOqQSw-UYphnLHx=6-6kkwA@mail.gmail.com' \
    --to=mahikolla@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=levraiphilippeblain@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.