Johannes Schindelin <johannes.schindelin@xxxxxx> writes: [...] > With this patch, the goodness of the Git garden shears comes to `git > rebase -i` itself. Passing the `--recreate-merges` option will generate > a todo list that can be understood readily, and where it is obvious > how to reorder commits. New branches can be introduced by inserting > `label` commands and calling `merge - <label> <oneline>`. And once this > mode has become stable and universally accepted, we can deprecate the > design mistake that was `--preserve-merges`. This doesn't explain why you introduced this new --recreate-merges. Why didn't you rather fix --preserve-merges to generate and use new todo list format? It doesn't seem likely that todo list created by one Git version is to be ever used by another, right? Is there some hidden reason here? Some tools outside of Git that use old todo list format, maybe? Then, if new option indeed required, please look at the resulting manual: --recreate-merges:: Recreate merge commits instead of flattening the history by replaying merges. Merge conflict resolutions or manual amendments to merge commits are not preserved. -p:: --preserve-merges:: Recreate merge commits instead of flattening the history by replaying commits a merge commit introduces. Merge conflict resolutions or manual amendments to merge commits are not preserved. Don't you think more explanations are needed there in the manual on why do we have 2 separate options with almost the same yet subtly different description? Is this subtle difference even important? How? I also have trouble making sense of "Recreate merge commits instead of flattening the history by replaying merges." Is it "<Recreate merge commits by replaying merges> instead of <flattening the history>" or is it rather "<Recreate merge commits> instead of <flattening the history by replaying merges>? -- Sergey
