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
