Hi Junio, On 20/02/2023 21:42, Junio C Hamano wrote: > Alex Henrie <alexhenrie24@xxxxxxxxx> 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? 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. > >> 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
