Hi Sergey, On Fri, 9 Feb 2018, Sergey Organov wrote: > 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? Because that would of course break existing users of --preserve-merges. So why not --preserve-merges=v2? Because that would force me to maintain --preserve-merges forever. And I don't want to. > It doesn't seem likely that todo list created by one Git version is to > be ever used by another, right? No. But by scripts based on `git rebase -p`. > Is there some hidden reason here? Some tools outside of Git that use old > todo list format, maybe? Exactly. I did mention such a tool: the Git garden shears: https://github.com/git-for-windows/build-extra/blob/master/shears.sh Have a look at it. It will inform the discussion. > 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. As I stated in the cover letter, there are more patches lined up after this patch series. Have a look at https://github.com/git/git/pull/447, especially the latest commit in there which is an early version of the deprecation I intend to bring about. Also, please refrain from saying things like... "Don't you think ..." If you don't like the wording, I wold much more appreciate it if a better alternative was suggested. > 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>? The documentation of the --recreate-merges option is not meant to explain the difference to --preserve-merges. It is meant to explain the difference to regular `git rebase -i`, which flattens the commit history into a single branch without merge commits (in fact, all merge commits are simply ignored). And I would rather not start to describe the difference between --recreate-merges and --preserve-merges because I want to deprecate the latter, and describing the difference as I get the sense is your wish would simply mean more work because it would have to be added and then removed again. If you still think it would be a good idea to describe the difference between --recreate-merges and --preserve-merges, then please provide a suggestion, preferably in the form of a patch, that adds appropriate paragraphs to *both* options' documentation, so that your proposal can be discussed properly. Ciao, Johannes
