Hi Dscho, On 11/03/2018 13:08, Johannes Schindelin wrote: > > > Hmm, funny enough, `pick <original merge>` was something I though about > > originally, too, feeling that it might make more sense in terms on > > what`s really going on, but I guess I wanted it incorporated into > > `--recreate-merges` too much that I tried really hard to fit it in, > > without changing it much :/ > > The `pick <original-merge>` syntax is too limited to allow reordering, let > alone changing the parents. I agree, `pick <original-merge>` syntax alone is never what I had in mind, so it`s missing further context here, touched in that other subthread[1]. My fault, sorry for confusion. > > pick <original-merge> <original-parent1>:HEAD <original-parent2>:<new-parent2> > > I do not really like it, as it makes things a ton less intuitive. If you > did not know about this here discussion, and you did not read the manual > (and let's face it: a UI that does not require users to read the manual is > vastly superior to a UI that does), and you encountered this command: > > merge deadbeef cafecafe:download-button > > what would you think those parameters would mean? > > Granted, encountering > > merge -R -C deadbeef download-button # Merge branch 'download-button' > > is still not *quite* as intuitive as I would wish. Although, to be honest, > if I encountered this, I would think that I should probably leave the -R > and the -C deadbeef alone, and that I could change what is getting merged > by changing the `download-button` parameter. Agreed, encountering mapping is slightly more complicated, but I would argue it`s much more powerful at the same time, too, thus pretty much worth it. Without it, actually, it seems like we`re repeating the mistake of `--preserve-merges`, where we`re assuming too much (order of new and old parents being the same, and I guess number of them, too). Oh, and as we`re still discussing in terms of `merge` command, using (elsewhere mentioned[1]) `pick` instead, it might be even less non-intuitive, as we`re not married to `merge` semantics any more: pick deadbeef cafecafe:download-button And might be calling it "non-intuitive" is unfair, I guess it would rather be "not familiar yet", being case with any new functionality, let alone a very powerful one, where getting a clue on what it does at the beginning could do wonders later. Sacrificing that power for a bit of perceived simplicity, where it actually assumes stuff on its own (trying to stay simple for the user), doesn`t seem as a good way to go in the long run. 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. But I`m still not sure if there isn`t a better way to present explicit mapping, just that <old>:<new> seemed as the most straightforward one to pass on the point for the purpose of discussing it. And I`m not reluctant to simplifying user interface, or for dropping the explicit mapping altogether, even, just for carefully measuring what we could lose without explicit mapping - think flexibility, but ease and correctness of implementation, too, as we need to guess the old merge parents and which new one they should correspond to. > > p.s. Are we moving towards `--rebase-merges` I mentioned in that > > other topic[1], as an add-on series after `--recreate-merges` hits > > the mainstream (as-is)...? :P > > That's an interesting question. One that I do not want to answer alone, > but I would be in favor of `--rebase-merges` as it is IMHO a much better > name for what this option is all about. Saying in favor of `--rebase-merges`, you mean as a separate option, alongside `--recreate-merges` (once that series lands)? That does seem as the most clean, intuitive and straightforward solution. Depending on the option you provide (recreate vs rebase), todo list would be populated accordingly by default - but important thing is "todo list parser" would know to parse both, so one can still adapt todo list to both recreate (some) and rebase (some other) merges at the same time. Of course, this only once `--rebase-merges` gets implemented, too, but as we had waited for it for so long, it won`t hurt to wait a bit more and possibly do it more properly, than rush it now and make a confusing user interface, needlessly welding two functionalities together (rebase vs. recreate). But I guess you already knew my thoughts, so let`s see what other`s think, too ;) Regards, Buga [1] https://public-inbox.org/git/f4e6237a-84dc-1aa8-150d-041806e2416e@xxxxxxxxx/
