Re: [PATCH 5/8] rebase: introduce the --recreate-merges option

edit: Sending again, hopefully without HTML :). Sorry for spamming.

Hi, I think --recreate-merges is a very exciting feature.

I've also been puzzled by why we can't just pick merge commits directly
including
conflict resolutions, so allow me to join the discussion.

On Wed, Feb 7, 2018 at 6:36 PM, Johannes Schindelin <Johannes.Schindeli
n@gmx.de> wrote:

Hi,

[...]

And guess what happens if you drop that `pick` line in your todo list

and

then the `merge` command simply tries to re-create the original merge
commit's changes?

Exactly. The merge will become an evil merge, and will introduce that

very

much not-wanted and therefore-dropped changes.

I think I understand. Evil merges happen when we change the branch
that is not the mainline..? Is there any reason why the following
wouldn't work?

Imagine rebase is about to pick a merge commit, and we have edited at
least one
commit in each branch to be merged.

1. apply patch mainline_orig..merge_orig
2. apply patch branch1_orig..branch1
...
N. apply patch branchN_orig..branchN
N+1. Commit merge

I do see complications, like the fact that steps 2-N can be done in any
order, with
possibly quite different results. Moving commits from one branch to
another might
not work very well. And what to do when you remove branches or create
new ones?

These problems might be prohibitive, but picking merge commits seems
like
something that should be possible to do.

[...]

So --preserve-merges --first-parent is probably what you were looking

for.

I want this as well :). I don't quite see the risk if it's not used
with --interactive.

[...]

So no, I do not think that --recreate-merges --first-parent is a good

idea

at all. Unless you try to do that non-interactively only, *and

disallow it

in interactive mode*. Because the entire point of the interactive

rebase

is to allow reordering and dropping commits, in --recreate-merges

even

moving, introducing and dropping merge commits. The --first-parent

option

flies in the face of this idea.

FWIW I'd be totally fine with disallowing it in --interactive. It would
be incredibly useful 
e.g. with pull --rebase in merge-based workflows.

BTW what is the difference between --recreate-merges and --preserve-
merges when
--interactive is not present? I apologize if you have explained this
somewhere
else in the patch series.

Ciao,
Johannes

Thanks,
Øyvind