Hi Sergey,
On 16/03/2018 08:31, Sergey Organov wrote:
>
> > > As I said, putting myself on the user side, I'd prefer entirely
> > > separate first step of the algorithm, exactly as written, with
> > > its own conflict resolution, all running entirely the same way as
> > > it does with non-merge commits. I'm used to it and don't want to
> > > learn something new without necessity. I.e., I'd prefer to
> > > actually see it in two separate stages, like this:
> > >
> > > Rebasing mainline of the merge...
> > > [.. possible conflicts resolution ..]
> > > Merging in changes to side branch(es)...
> > > [.. possible conflicts resolution ..]
> > >
> > > And if the second stage gives non-trivial conflicts, I'd like to
> > > have a simple way to just do "merge -s ours <heads>" on top of
> > > already rebased mainline of the merge and go with it. Note that
> > > the latter is significantly different than re-merging everything
> > > from scratch, that would be the only choice with "all-in-one"
> > > approach, and it essentially gives me back those simple "rebase
> > > first parent and just record other parents" semantics when
> > > needed.
> >
> > [...]
> >
> > Also note that, for example, in case side branch(es) dropped some
> > commits (interactively or otherwise), first step alone would still
> > reintroduce those dropped changes, thus later possible `merge -s ours
> > <heads>` would be a pretty bad "evil merge" case and a wrong thing to
> > do in general.
>
> Except that my presumption is that the second step has been run already
> and has stopped due to conflicts, so I see the conflicting result of
> dropping those commits on side branch(es), check the previous state of
> the right side of the conflicting merge, and decide those state, being
> the result of the fist step after possibly demanding conflicts
> resolution, is fine after all. Thus I just re-merge -x ours the
> branch(es), instead of re-merging everythig from scratch only to finally
> get back to the same result, be it evil or not, the hard way.
Might be my comment missed the point here, it should have been more
about what you said regarding "first step having its own conflict
resolution" - in case of dropped commits on side branch(es), you would
be trying to resolve conflicts using one tree that doesn`t/shouldn`t
even exist anymore (rebased merge commit first parent changes), which
might be pretty confusing, only to find the "second stage" later
removing changes that you might have actually picked as "first stage"
conflict resolution, making it all even worse.
Only once "huge merge" is done completely (meaning all steps involved
in merge commit rebasing), user can have a more realistic overview of
(possibly nested, even) conflicts to resolve (and knowing his resolution
will actually stick).
Regarding `merge -s ours <heads>` you mention, as you say it would
happen only after "huge merge" is complete (with possible conflicts),
I guess it`s unrelated to having "merge commit rebasing" happen in
one go ("huge merge"), or iteratively, in stages (from user`s
perspective, unrelated to underlying implementation)...?
Thus I`m questioning use-case for step-by-step merge commit rebasing
where each stage has its own conflict resolution, in the face of it
possibly being more confusing than helpful.
Otherwise, I see the point in what you would like to accomplish with
that `merge -s ours <heads>` (not from scratch), but I`m not sure
what would be the most sane way to allow it, and if it would be worth
it in the first place, seeming to be a pretty exotic use case.
Regards, Buga
