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

From: Johannes Sixt <j6t@kdbg.org>
Date: Feb 9, 2018, 07:13 UTC
Message-ID: <ec5c7aa2-b36b-aca8-d82f-9d131ac83b41@kdbg.org>
In-Reply-To: <87o9kyitf7.fsf@javad.com>

Am 09.02.2018 um 07:11 schrieb Sergey Organov:

Show 12 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Let me explain the scenario which comes up plenty of times in my work with
>> Git for Windows. We have a thicket of some 70 branches on top of git.git's
>> latest release. These branches often include fixup! and squash! commits
>> and even more complicated constructs that rebase cannot handle at all at
>> the moment, such as reorder-before! and reorder-after! (for commits that
>> really need to go into a different branch).
> 
> I sympathize, but a solution that breaks even in simple cases can't be
> used reliably to solve more complex problems, sorry. Being so deep
> into your problems, I think you maybe just aren't seeing forest for the
> trees [1].

Hold your horses! Dscho has a point here. --preserve-merges --first-parent works only as long as you don't tamper with the side branches. If you make changes in the side branches during the same rebase operation, this --first-parent mode would undo that change. (And, yes, its result would be called an "evil merge", and that scary name _should_ frighten you!)

-- Hannes