git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Mahi Kolla <mahikolla@google.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 22:02:41 -0700	[thread overview]
Message-ID: <xmqqbl64bmku.fsf@gitster.g> (raw)
In-Reply-To: xmqqa6lpdu4z.fsf@gitster.g

Junio C Hamano <gitster@pobox.com> writes:

> Mahi Kolla <mahikolla@google.com> writes:
>
>>> 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.

Let me outline some general rules on changing the behaviour of the
system used around here.

First of all, if a proposed change of behaviour is a bugfix, the
following does not apply [*1*].

When a new behaviour is made available to those who want to use it,
it starts as an opt-in feature.

 - Existing users will not be surprised by a familiar command
   suddenly changing its behaviour.  If users keep using the system
   the same way as they used it before, the system will behave the
   same way, without changing the behaviour.

 - Those who want to use the new behaviour need to do something to
   explicitly trigger it (with a command line option, configuration
   variable, a new command, etc.)

Over time, a behaviour that used to be a "new way" may just become
"one of the two ways available", and it may even turn out to be a
more desirable one between the two.  At that point, we may propose
to flip the default, with a migration plan that is carefully
designed to avoid breaking existing users.

Even if it were an *improvement* to set the configuration variable,
it is not an excuse to suddenly change the behaviour of the command
for users who do not ask.  It needs to start as an optional feature,
and if we really like it and manage to convince majority users to
also like the new way, we may even consider making it the default,
but it is way too premature to do so.

Unless we can argue that the current behaviour *is* buggy, that is.

Thanks.


[Footnote]

*1* A change that we have to say "not all users may be happy with
    this new behaviour" or "developers would be surprised by the new
    behaviour" cannot be a bugfix.

  parent reply	other threads:[~2021-08-11  5:02 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
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 [this message]
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

  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=xmqqbl64bmku.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=levraiphilippeblain@gmail.com \
    --cc=mahikolla@google.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.
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).