On Wed, Mar 21, 2018 at 5:32 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Paul, >
> Note! There is one exception, and it is not even a full script. As > everybody knows who follows my patch series on this here mailing list, I > consider --preserve-merges one of my stupidest design mistakes ever. To > undo this (or at least to alleviate the damage I caused), I already > submitted a patch series to introduce a superseding option: > --recreate-merges. This patch series is on hold due to the -rc phase of > v2.17 and will be kicked back into action after v2.17.0 final is out. As > it is my hope that --preserve-merges can be deprecated in favor of > --recreate-merges (and eventually even phased out of Git), I would be > totally cool with git-rebase--preserve-merges.sh being factored out of > git-rebase--interactive.sh before converting the latter to pure C, and > leaving the --preserve-merges script alone until the time when it is put > to rest. > > (While I was sleeping, leaving this mail unfinished, to be completed and > sent today, a patch series was sent to the mailing list that seems to > perform this refactoring of --preserve-merges into its own script.) I plead guilty to being the preson refactoring --preserve-merges. But after reading this and seeing that --recreate-merges is coming and possibly git-rebase--* moving to C I'm worried I'd be messing things up. Also, Eric Sunshine felt my v1 changes causes the blame information to be obscured. So I created a v2 change which keeps everything in the git-rebase--interactive.sh. Please see "[RFC PATCH 0/3] rebase-interactive" and "[RFC PATCH v2 0/1] rebase-interactive: ...". I'm looking for advice on how to proceed.
