Hi Junio, On Sat, 22 Oct 2016, Junio C Hamano wrote: > Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > > > This patch series marks the '4' in the countdown to speed up rebase -i > > by implementing large parts in C (read: there will be three more patch > > series after that before the full benefit hits git.git: sequencer-i, > > rebase--helper and rebase-i-extra). > > ... > > It would be *really* nice if we could get this patch series at least > > into `next` soon, as it gets late and later for the rest of the > > patches to make it into `master` in time for v2.11 (and it is not for > > lack of trying on my end...). > > This "countdown 4" step can affect cherry-pick and revert, even > though we were careful to review changes to the sequencer.c code. As I pointed out in another mail in this thread: we should not fall into the trap of overrating review. In the case of the rebase--helper patches, so far the review mainly resulted in more work for me (having to change spellings elsewhere, for example), not in improving the changes I intended to introduce into git.git's code. Sure, there has been the occasional improvement, but it certainly feels as if I spent about 80% of the work after each -v1 iteration on things that have positively nothing at all to do with accelerating rebase -i. > I prefer to cook it in 'next' sufficiently long to ensure that we hear > feedbacks from non-Windows users if there is any unexpected breakage. FWIW I am using the same patches not only on Windows but also in my Linux VM. > There isn't enough time to include this topic in the upcoming > release within the current https://tinyurl.com/gitCal calendar, > however, which places the final on Nov 11th. More is the pity. Thank you, though, for being upfront with me. I will shift my focus to tasks that require my attention more urgently, then. Ciao, Dscho