From: "Matwey V. Kornilov" <firstname.lastname@example.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: rebase preserve-merges: incorrect merge commits
Date: Mon, 8 Jan 2018 20:24:05 +0300 [thread overview]
Message-ID: <CAJs94EYrBgNW-bzoEgy9=fStJW2esoULxfOHX45V63HavqOCpw@mail.gmail.com> (raw)
2018-01-08 19:32 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
>> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov <email@example.com>:
>> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> >> 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.
With best regards,
Matwey V. Kornilov
next prev parent reply other threads:[~2018-01-08 17:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 10:24 rebase preserve-merges: incorrect merge commits Matwey V. Kornilov
2018-01-08 13:56 ` Johannes Schindelin
2018-01-08 14:42 ` Matwey V. Kornilov
2018-01-08 14:46 ` Matwey V. Kornilov
2018-01-08 16:32 ` Johannes Schindelin
2018-01-08 17:24 ` Matwey V. Kornilov [this message]
2018-01-08 19:36 ` Johannes Schindelin
2018-01-09 9:49 ` Matwey V. Kornilov
2018-01-09 13:25 ` Johannes Schindelin
2018-01-09 14:19 ` Matwey V. Kornilov
2018-01-09 16:29 ` Johannes Schindelin
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).