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
