Hi Junio, On Tue, 27 Aug 2019, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. > > >> > + 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 This is what I had in mind. > add.patch.usebuiltin = no And this is what I should have done ;-) But maybe I should do add.useBuiltin = wheneverPossible ? Ciao, Dscho > > perhaps? > > > Of course, eventually this will be handled. > > Yup, again, the knob is merely temporary.
