Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)
- From
Sergey Organov <sorganov@gmail.com>
- Date
- Mar 5, 2018, 05:35 UTC
- 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