Hi Junio, On Wed, 7 Feb 2018, Junio C Hamano wrote: > Øyvind Rønningstad <ronningstad@xxxxxxxxx> writes: > > >> So no, I do not think that --recreate-merges --first-parent is a good > > idea > >> at all. Unless you try to do that non-interactively only, *and > > disallow it > >> in interactive mode*. > > Correct. If the original side branch has commits A, B and C, you > are rebuilding the topic to have only A and C but not B and then > recreate the merge of that rebuilt topic, then you absolutely do not > want "cherry-pick -m1" of the original merge when recreating the > merge, as that would resurrect the effect of having B. The same > argument applies if you rebuilt the topic with A and C and then a > new commit D. "cherry-pick -m1" of the original would do a wrong > thing. > > When there is no such fixing up, "cherry-pick -m1" is the right > thing to do, though, so it probably makes sense to pick merges that > way when the side topic being merged consists of the same commits as > the original. Please note that there are a lot of conditions of "fixing up". A lot more than just dropping, reordering or adding `pick`s. > I do not think that the code structure in the topic as posted makes it > impossible (or unnecessarily hard) to give an enhancement like that in > the future as a follow-up series. Just to give you one concrete example: when I recently rebased some patches (no reording or dropping involved here!) and one of the picks failed with merge conflicts, I realized that that particular commit introduced incorrect formatting and fixed that right away (verifying that no other commits introduced incorrect formatting, of course). With your new cute idea to magically cherry-pick -m1, this change would have been magically dropped from the subsequent merge commits! And let me pick a bit on the statement "I do not think that ... makes it impossible (or unnecessarily hard) ...": I absolutely agree. I absolutely agree that it is not impossible or unnecessarily hard to introduce features *that are confusing the users because they are inconsistent with the expectations how such a command should operate*. So the question is not so much whether we can introduce a feature that makes no sense. Of course we can, we are decent software developers. The question is: will this be confusing, inconsistent behavior that violates the Principle of Least Surprise? In that respect, introducing conditional code that would `cherry-pick -m1` when the todo list is unchanged so far (and only then) is an absolute no, no, no. It would be all three: confusing, inconsistent and violating the Principle of Least Surprise. So how about introducing support for `--recreate-merges --first-parent` and allowing to combine it with `--interactive`? Also violating all three. I can see how you *could* argue that `--recreate-merges --first-parent` is a Good Thing. I really can. It would even recreate evil merges. But in interactive mode? Nope. It would cause all kind of pain, not the least on me, because I know how many people ask me about `--preserve-merges --interactive` and its confusing and inconsistent behavior that violates the Principle of Least Surprise. So as long as y'all don't go anywhere near "oh, let's just introduce --recreate-merges --first-parent and *then also support it in --interactive because we can even if it hurts the user experience", I agree that it could be a good follow-up patch series. Taking a step back, I have to wonder, though, why we stumble over our feet trying to cross bridges that are one farther than the one we currently have to cross. By now, it should be clear why the default mode of --recreate-merges *cannot* be --first-parent. And before --recreate-merges is said and done, we should maybe work on getting it said and done, rather than musing about what comes next? I, for one, would really like to focus my time on getting *this* patch series reviewed and included. Thanks, Johannes
