From: Sergey Organov <sorganov@gmail.com>
Date: Mon, 05 Mar 2018 05:35:22 GMT
Subject: Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)
Message-ID: <878tb7m6ed.fsf@javad.com>
In-Reply-To: <39aebd06-6022-7803-e27d-c1793fd72955@gmail.com>

Hi Igor,

Igor Djordjevic <igor.d.djordjevic@gmail.com> writes:

[...]

> Now, not to get misinterpreted to pick sides in "(re)create" vs 
> "rebase" merge commit discussion, I just think these two (should) have 
> a different purpose, and actually having both inside interactive rebase 
> is what we should be aiming for.

Yes, if the user has an existing merge that he intends to throw away by
re-merging from scratch, he should be given a way to do it during
history editing session, no argues.

What I argue against is that this mode of operation is the default one,
let alone the only one.

> And that`s what I think is important to understand before any further 
> discussion - _(re)creating_ existing merge commits is not the same as 
> _rebasing_ them, even though the former can sometimes be used to 
> achieve the latter.

Yes, indeed. Sometimes creating new merge instead of original does the
job of rebasing the original, only it does it by pure accident.

-- Sergey