Junio C Hamano <gitster@xxxxxxxxx> writes: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > >> base-commit: 2d4b85ddc76af3e703e6e3a6a72319b5e79c2d8b > > It is not generally helpful to those who reads this list to use a > commit that is not part of history leading to my 'pu' or 'next' as > the base. I think there was only one spot that needed adjusting to the newer iteration of the js/patch-mode-in-others-in-c series. This may have started as "there are some configuration variables that are ignored in the C version, fix them" and that may be why the pull-request branch says "config-settings", but overall, I think the bulk of the change ends up being a "how would we implement the annoying-to-implement-portably single-key behaviour". I think it is a mistake to write the lower-level terminal access code without using established libraries (or write it with a higher level abstraction offered by scripting languages like Perl and Pythnon), and I would personally take, given a choice between accepting such maintenance/porting liability and dropping of single-key behaviour, the latter in any second. I wonder if it makes sense to split this series into two so that the early and easier part for leftover config bits can graduate separately early in the next cycle, instead of letting the parts that tackles the terminal nightmare (note that the problem being nightmare is not the fault of this topic) which would inevitably take more time to stabilize take the remainder of the series hostage to it. Thanks.
