Hi Junio,

On 20/02/2023 21:42, Junio C Hamano wrote:

Alex Henrie [off-list ref] writes:

quoted

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?

While "flatten.." is used on list, we rarely mention it in our man
pages, and usually only in a cautionary manner via the
rev-list-options.txt under "--show-linear-break".

It's not always clear what is meant by 'flattening' and which aspects
are included/excluded from the flattened display. I suspect that a
recent question on the git-users list [1] originates from the same
confusions.

Maybe it's something that could be included in the Glossary to
supplement the not well known how-to discussion in
keep-canonical-history-correct.txt

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.

quoted

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?

[1]
https://groups.google.com/d/msgid/git-users/057bd9e2-b20b-4794-b8a0-bc16ede374c1n%40googlegroups.com

--

Philip