Hi Dscho, On 12/03/2018 11:46, Johannes Schindelin wrote: > > > Sometimes one just needs to read the manual, and I don`t really think > > this is a ton complicated, but just something we didn`t really have > > before (real merge rebasing), so it requires a moment to grasp the > > concept. > > If that were the case, we would not keep getting bug reports about > --preserve-merges failing to reorder patches. Not sure where that is heading to, but what I`m arguing about is that introducing new commands and concepts (`merge`, and with `-R`) just makes the situation even worse (more stuff to grasp). Reusing existing concepts where possible doesn`t have this problem. > > Saying in favor of `--rebase-merges`, you mean as a separate option, > > alongside `--recreate-merges` (once that series lands)? > > No. I am against yet another option. The only reason I pollute the option > name space further with --recreate-merges is that it would be confusing to > users if the new mode was called --preserve-merges=v2 (but work *totally > differently*). I see. So I take you`re thinking about renaming `--recreate-merges` to `--rebase-merges` instead? That would seem sensible, too, I think, being the default usage mode in the first place. Being able to actually (re)create merges, too, once user goes interactive, would be "just" an additional (nice and powerful) feature on top of it. Regards, Buga
