Hi Sergey, On Thu, 12 Apr 2018, Sergey Organov wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Wed, 11 Apr 2018, Sergey Organov wrote: > > > >> The RFC v2 and Phillip's strategy are essentially the same, as has been > >> already shown multiple times, both theoretically and by testing. > > > > No, they are not. > > It's off-topic here. Well, you directed the discussion there. So there. > If you _really_ want to discuss it further [...] I am always interested in a constructive discussion toward the goal of making Git better, to improve its user experience, to give users more powerful options, and to make things easier to use. I'll let you know when I detect a change in this discussion in that vague direction. > Abrupt change of the topic of discussion indicates your intention to > take attention off the apparent ugliness of > > git rebase --rebase-merges If you want to discuss ugly things in Git, that is really an abrupt diversion, but I would not fault you: there is plenty of that in Git. As to `git rebase --rebase-merges`? I do not actually find that really ugly. I find that it says what I want it to say. And after how many people agreed, I find it rather pointless and time-wasting to discuss this further. Naming is hard, and you seem to have a knack for coming up with names that are really terrible. That is why I stopped discussing this with you. > I also get it as an indication that there are no more arguments in favor > of --rebase-merges on your side, at least for now. You seem to misinterpret your own arguments against --rebase-merges to be anywhere in the realm of convincing. They are not. Did I say "flatten history" to you in this discussion? Sure I did. We also talked about Darcs. About the theory of patches. About the inner workings of recursive merges. About commit graphs. And topologies. And we threw around many terms that we know people understand who are deep into the inner workings of merges and cherry-picks. Does this mean that we should expose all the terms we used in this technical discussion to the user interface? No, it does not. We should not absolutely not do that. So it is not at all a convincing argument to say "but you said XYZ". *In this mail thread*. Which is necessarily full of technical lingo. Also, I am still waiting for something tangible from your side. Something non-theoretic. Something practical. Something like taking that FAKE_INIT example at heart, studying it, deducing from it what weaknesses we cannot tolerate in strategies to "cherry-pick merge commits" or "forward-port merges" or "re-apply amendments in merge commits" or whatever you want to call it. Your suggestions so far are heavily biased by your own preferences, based in theoretical musings, not in practical examples. I do not see any focus on the Git user base at large. "What? They don't know what a topology is?" is a question I could see you asking. There has been a lot of talk in this mail thread, and the only actual outcome I see is my own work, and Buga's tireless efforts to test approaches for their practicality. There is zilch concrete testing from your side. No implementation of anything. No demonstration what kinds of merge conflicts are produced, how often they would have to be resolved by the user. None. The important thing to keep in mind is that all my efforts here are spent in order to come up with a feature in Git that empowers users. And I want this feature to be as usable as possible. And I want it to use as simple language and option names as possible. That is what I will keep focusing on, like it or not. Ciao, Johannes
