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

From: Sergey Organov <sorganov@gmail.com>
Date: Feb 7, 2018, 06:16 UTC
Message-ID: <87k1vpqq85.fsf@javad.com>
In-Reply-To: <71c42d6d3bb240d90071d5afdde81d1293fdf0ab.1516225925.git.johannes.schindelin@gmx.de>

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

[...]

> +--recreate-merges::
> +	Recreate merge commits instead of flattening the history by replaying
> +	merges. Merge conflict resolutions or manual amendments to merge
> +	commits are not preserved.

I wonder why you guys still hold on replaying "merge-the-operation" instead of replaying "merge-the-result"? The latter, the merge commit itself, no matter how exactly it was created in the first place, is the most valuable thing git keeps about the merge, and you silently drop it entirely! OTOH, git keeps almost no information about "merge-the-operation", so it's virtually impossible to reliably replay the operation automatically, and yet you try to.

IMHO that was severe mistake in the original --preserve-merges, and you bring with you to this new --recreate-merges... It's sad. Even more sad as solution is already known for years:

    bc00341838a8faddcd101da9e746902994eef38a
    Author: Johannes Sixt <j6t@kdbg.org>
    Date:   Sun Jun 16 15:50:42 2013 +0200
    
        rebase -p --first-parent: redo merge by cherry-picking first-parent change

and it works like a charm.

-- Sergey