Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
> Changes since v8:
>
> - Disentangled the patch introducing `label`/`reset` from the one
> introducing `merge` again (this was one stupid, tired `git commit
> --amend` too many).
>
> - Augmented the commit message of "introduce the `merge` command" to
> describe what the `label onto` is all about.
>
> - Fixed the error message when `reset` would overwrite untracked files to
> actually say that a "reset" failed (not a "merge").
>
> - Clarified the rationale for `label onto` in the commit message of
> "rebase-helper --make-script: introduce a flag to rebase merges".
>
> - Edited the description of `--rebase-merges` heavily, for clarity, in
> "rebase: introduce the --rebase-merges option".
>
> - Edited the commit message of (and the documentation introduced by) " rebase
> -i: introduce --rebase-merges=[no-]rebase-cousins" for clarity (also
> mentioning the `--ancestry-path` option).
>
> - When run_git_commit() fails after a successful merge, we now take pains
> not to reschedule the `merge` command.
>
> - Rebased the patch series on top of current `master`, i.e. both
> `pw/rebase-keep-empty-fixes` and `pw/rebase-signoff`, to resolve merge
> conflicts myself.
Good to see the last item, as this gave me a chance to make sure
that the conflict resolution I've been carrying matches how you
would have resolved as the original author. Applying these on the
old base (with minor conflict resolution) to match the old iteration
and merging the result to the new base1f1cddd5 ("The fourth batch
for 2.18", 2018-04-25) resulted in the same tree as the tree that
results from applying these on top of the new base.
That was done only to validate the result of the past resolution
(and also seeing the interdiff from the old iteration). There is no
reason to keep this series back-portable to older tip of 'master',
so I'll queue the result of applying the patches to the new base.
