Re: [PATCH v4] clone: update submodule.recurse in config when using --recurse-submodule

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Mahi Kolla <mahikolla@xxxxxxxxxx> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux