Hi Buga,
Igor Djordjevic <igor.d.djordjevic@xxxxxxxxx> writes:
> 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.
I find your arguments sound, except that I somehow feel that "exotic use
case" will solve 90% of conflicting merge rebases, as merges are about
the mainline in the first place. It's likely nothing more than personal
feeling though, so I'd simply agree to disagree at this point, at least
until some actual experience is gained.
-- Sergey
