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

From: Sergey Organov <sorganov@gmail.com>
Date: Feb 14, 2018, 05:41 UTC
Message-ID: <87vaf03z78.fsf@javad.com>
In-Reply-To: <nycvar.QRO.7.76.6.1802081317320.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: [...]

Show 8 quoted lines

> Just to give you one concrete example: when I recently rebased some
> patches (no reording or dropping involved here!) and one of the picks
> failed with merge conflicts, I realized that that particular commit
> introduced incorrect formatting and fixed that right away (verifying that
> no other commits introduced incorrect formatting, of course).
>
> With your new cute idea to magically cherry-pick -m1, this change would
> have been magically dropped from the subsequent merge commits!

You put it as if the problem you describe is unsolvable short of getting back to your favorite blind re-merge. Do you really believe it?

I thought it's obvious that I originally meant "cherry-pick -m1" to be an explanation facility, a proof of concept, not the final answer to all the problems of history editing. It's a nice base for actually approaching these problems though, unlike blind re-merge currently being used, the latter having no potential.

The fact that bare naked "cherry-pick -m1" doesn't do what is often[1] required in such cases neither voids the general idea of reproducing merge-the-result, nor does it make current re-merge approach less broken.

[1] Please take into consideration that it's _not always_ the case that one needs a change made to a side-branch to actually propagate to the main-line over the merge (think "merge -x ours", or something similar but not that simple), and then it's rather the cute idea to blindly re-merge that will wreak havoc, as in a lot of other cases.

-- Sergey