Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Buga,

On Thu, 8 Mar 2018, Igor Djordjevic wrote:

On 08/03/2018 12:20, Phillip Wood wrote:

quoted

I did wonder about using 'pick <original-merge>' for rebasing merges
and keeping 'merge ...' for recreating them but I'm not sure if that
is a good idea. It has the advantage that the user cannot specify the
wrong parents for the merge to be rebased as 'git rebase' would work
out if the parents have been rebased, but maybe it's a bit magical to
use pick for merge commits. Also there isn't such a simple way for the
user to go from 'rabase this merge' to 'recreate this merge' as they'd
have to write the whole merge line themselves (though I guess
something like emacs' git-rebase.el would be able to help with that)

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.

And now that I said this in a previous reply:

quoted

The thing is, in my opinion, as long as we are _rebasing_, you can`t 
pick any merge strategy, as it doesn`t really make much sense. If you 
do want a specific strategy, than that`s _recreating_ a merge, and it 
goes fine with what you already have for `--recreate-merges`.

On merge rebasing, the underline strategy we decide to use is just an 
implementation detail, picking the one that works best (or the only 
one that works, even), user should have nothing to do with it.

The difference between "rebase merge commit" and "recreate merge 
commit" might starting to be more evident.

True.

So... I might actually go for this one now. And (trying to stick with 
explicit mappings, still :P), now that we`re not married to `merge` 
expectations a user may already have, maybe a format like this:

  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.

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.

Other opinions?

Ciao,
Dscho