Re: [PATCH v3 2/5] repo-settings: add feature.manyCommits setting

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 31, 2019, 15:48 UTC
Message-ID: <xmqq1ry6ryr5.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.1907311515210.21907@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 15 quoted lines

> On Tue, 30 Jul 2019, Junio C Hamano wrote:
>
>> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>
>> > +#define UPDATE_DEFAULT(s,v) do { if (s == -1) { s = v; } } while(0)
>>
>> [...]
>>  3. When we learn to set default values for variables that are not
>>     boolean in the future, we will regret that we did not name it
>>     UPDATE_DEFAULT_BOOL(slot, value).
>
> On the other hand, as we never promised any kind of API (and this is not
> even an internal API to begin with), it will be _easy_ to rename it in
> the unlikely event that we would ever introduce non-boolean defaults to
> override, wouldn't you agree?

I agree that it is easy to say that it is easy to rename it later and burden somebody else with the task.

I know that the renaming itself is easy, when you limit yourself within the scope of a single topic, whether done now or later. I also know that having to worry about other topics in flight has non-zero cost. I also know that you are not the one who will bear it---I will be.

So from my point of view, if we can make a prediction, even with limited knowledge that a name may need to be renamed in the future, it is better not pick such a name and instead use one that we think it has a better chance of surviving without needing a rename.