Hi Matwey, On Tue, 9 Jan 2018, Matwey V. Kornilov wrote: > 2018-01-08 22:36 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@xxxxxx>: > > > > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote: > > > >> 2018-01-08 19:32 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@xxxxxx>: > >> > > >> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote: > >> > > >> >> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@xxxxxxxxx>: > >> >> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@xxxxxx>: > >> >> >> Hi Matwey, > >> >> >> > >> >> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote: > >> >> >> > >> >> >>> I think that rebase preserve-merges algorithm needs further > >> >> >>> improvements. Probably, you already know it. > >> >> >> > >> >> >> Yes. preserve-merges is a fundamentally flawed design. > >> >> >> > >> >> >> Please have a look here: > >> >> >> > >> >> >> https://github.com/git/git/pull/447 > >> >> >> > >> >> >> Since we are in a feature freeze in preparation for v2.16.0, I will > >> >> >> submit these patch series shortly after v2.16.0 is released. > >> >> >> > >> >> >>> As far as I understand the root cause of this that when new merge > >> >> >>> commit is created by rebase it is done simply by git merge > >> >> >>> $new_parents without taking into account any actual state of the > >> >> >>> initial merge commit. > >> >> >> > >> >> >> Indeed. preserve-merges does not allow commits to be reordered. (Actually, > >> >> >> it *does* allow it, but then fails to handle it correctly.) We even have > >> >> >> test cases that mark this as "known breakage". > >> >> >> > >> >> >> But really, I do not think it is worth trying to fix the broken design. > >> >> >> Better to go with the new recreate-merges. (I am biased, of course, > >> >> >> because I invented recreate-merges. But then, I also invented > >> >> >> preserve-merges, so ...) > >> >> > > >> >> > Well. I just checked --recreate-merges=no-rebase-cousins from the PR > >> >> > and found that it produces the same wrong result in my test example. > >> >> > The topology is reproduced correctly, but merge-commit content is > >> >> > broken. > >> >> > I did git rebase --recreate-merges=no-rebase-cousins --onto abc-0.1 v0.1 abc-0.2 > >> >> > >> >> Indeed, exactly as you still say in the documentation: "Merge conflict > >> >> resolutions or manual amendments to merge commits are not preserved." > >> >> My initial point is that they have to be preserved. Probably in > >> >> recreate-merges, if preserve-merges is discontinued. > >> > > >> > Ah, but that is consistent with how non-merge-preserving rebase works: the > >> > `pick` commands *also* do not record merge conflict resolution... > >> > > >> > >> I am sorry, didn't get it. When I do non-merge-preserving rebase > >> --interactive there is no way to `pick' merge-commit at all. > > > > Right, but you can `pick` commits and you can get merge conflicts. And you > > need to resolve those merge conflicts and those merge conflict resolutions > > are not preserved for future interactive rebases, unless you use `rerere` > > (in which case it also extends to `pick`ing merge commits in > > merge-preserving mode). > > Are you talking about merge conflicts arising due to commits reordering? Merge conflicts can arise from commit reordering, and they can also arise from commits introduced in "upstream" in the meantime. Ciao, Johannes
