"Philip Oakley" <philipoak...@iee.org> writes: >> +-r:: >> +--rebase-merges:: >> + By default, a rebase will simply drop merge commits and only rebase >> + the non-merge commits. With this option, it will try to preserve >> + the branching structure within the commits that are to be rebased, >> + by recreating the merge commits. If a merge commit resolved any merge >> + or contained manual amendments, then they will have to be re-applied >> + manually. >> ++ >> +This mode is similar in spirit to `--preserve-merges`, but in contrast to >> +that option works well in interactive rebases: commits can be reordered, >> +inserted and dropped at will. >> ++ >> +It is currently only possible to recreate the merge commits using the >> +`recursive` merge strategy; Different merge strategies can be used only >> via >> +explicit `exec git merge -s <strategy> [...]` commands. >> + >> -p:: >> --preserve-merges:: >> Recreate merge commits instead of flattening the history by replaying > > Flatten is here in the context lines but its just a blunt statement that 'it > is what it is'...
The first paragraph that explains --rebase-merges talks about what happens when the option is not given, and says "drop merge commits and only rebase the non-merge commits", which is not incorrect per-se but does not make it explicit how the resulting topology looks like. I think it is easier to understand if it mentioned "flattening" as well. If flatten is not the word you want, perhaps "make it linear" or something like that?
