Re: [PATCH 1/2] rebase: add a --rebase-merges=drop option

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 20, 2023, 21:42 UTC
Message-ID: <xmqqr0ukggk5.fsf@gitster.g>
In-Reply-To: <20230220033224.10400-1-alexhenrie24@gmail.com>

Alex Henrie <alexhenrie24@gmail.com> writes:

> Name the new option "drop" intead of "no" or "false" to avoid confusion

This is traditionally called "flattening the history". Don't we confuse uesrs by introducing a new phrase?

rebase-merges is about transplanting the history without flattening, i.e. keeping the mergy commit graph topology. If there are only two kinds of rebase (i.e. keeping the topology which is rebase-merges and the other "flattening" kind) operation, shouldn't the option be called "--no-rebase-merges" instead? --rebase-merges=no is also understandable.

> in the future if --rebase-merges grows the ability to truly "rebase"
> merge commits by reusing the conflict resolution information from the
> original merge commit, and we want to add an option to ignore the
> conflict resolution information.

I am not sure why such a change "in the future" is not merely a bugfix of the current "--rebase-merges", though. Once it is fixed, is there a reason to make the fixed behaviour only available behind an option?