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. 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) `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
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, 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 ;)