Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: [...] > 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
