Hi Junio, On Tue, 13 Dec 2016, Junio C Hamano wrote: > Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > > > Apart from mostly cosmetic patches (and the occasional odd bug that I > > fixed promptly), I used these patches since mid May to perform all of my > > interactive rebases. In mid June, I had the idea to teach rebase -i to > > run *both* scripted rebase and rebase--helper and to cross-validate the > > results. This slowed down all my interactive rebases since, but helped > > me catch three rather obscure bugs (e.g. that git commit --fixup unfolds > > long onelines and rebase -i still finds the correct original commit). > > ... > > Please note that the interdiff vs v1 is only of limited use: too many > > things changed in the meantime, in particular the prepare-sequencer > > branch that went through a couple of iterations before it found its way > > into git.git's master branch. So please take the interdiff with a > > mountain range of salt. > > ... > > Changes since v1: > > ... > > - removed the beautiful ordinal logic (to print out "1st", "2nd", "3rd" > > etc) and made things consistent with the current `rebase -i`. > > It was removed because it was too Anglo-centric and unusable in i18n > context, no? Yes, but I remember putting in a lot of time to try to come up with the most elegant way to convert a number into an English ordinal in a shell function. That's where all that wistfulness came from. > Judging from the list above, interdiff are pretty much all cosmetic > and that is why you say it is only of limited use, I guess. No, I said that it is only of limited use because I had to fudge things to come up with an interdiff. I had to fudge things because there is no interdiff: it would require the previous iteration of the patch series to apply cleanly to the current `master`, which it does not. So I rebased the patches and left as much intact as possible, which means that the rebased changes do not even compile because they were based on a previous iteration of the prepare-sequencer patch series that did not make it into `master` without substantial changes. > ... goes and reads the remainder and finds that these were > ... all minor changes, mostly cosmetic, with a helper function > ... refactored out or two and things of that nature. > > It is actually a good thing. We do not want to see it deviate too > drastically from what you have been testing for some months. Well, that ship has sailed. Neither of the patch series "require-clean-work-tree", "libify-sequencer" and "prepare-sequencer" made it into `master` without substantial deviations from the code I had been testing and improving for half a year. I did not expect the code to be accepted unchanged, anyways. Ciao, Dscho