Hi Buga,
On Thu, 8 Mar 2018, Igor Djordjevic wrote:
> On 08/03/2018 12:20, Phillip Wood wrote:
> >
> > 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:
>
> > 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
