Re: [PATCH v3 01/11] Start to implement a built-in version of `git add --interactive`

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 27, 2019, 22:25 UTC
Message-ID: <xmqq5zmi2qkp.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.1908262317250.46@tvgsbejvaqbjf.bet>

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

> Besides, I really hope that this would be only temporary,...

Oh, no question about it.  This should be temporary knob.

I still do worry about giving a bad example for others to copy. People tend to copy & paste without thinking. Either we come up with and use a two-level name, or we add a comment to explain to developers (not users---as this is merely a temporary thing) why they should never follow suit using three-level names for things like this one written in big red letters, or something, then perhaps we won't have to worry about too much? I dunno.

Show 10 quoted lines

>> > +	if (use_builtin_add_i == 1 && !patch_mode)
>> > +		return !!run_add_i(the_repository, pathspec);
>>
>> I am hoping that eventually "add -p" will also be routed to the new
>> codepath.  Would it make sense to have "&& !patch_mode" here,
>> especially at this step where run_add_i() won't do anything useful
>> anyway yet?
>
> The `&& !patch_mode` is here to allow for a gradual adoption of the
> built-in parts. ...

Ah, so "add.usebuiltin = interactive patch" can (eventually) choose to use the C code for both while "add.usebuiltin = interactive" would not use it for the patch mode, or something? Or even

	add.interactive.usebuiltin = yes
	add.patch.usebuiltin = no

perhaps?

> Of course, eventually this will be handled.

Yup, again, the knob is merely temporary.