From: Junio C Hamano Date: Wed, 12 Nov 2008 22:04:35 GMT Subject: Re: overly smart rebase - bug or feature? Message-ID: <7v63msmwi4.fsf@gitster.siamese.dyndns.org> In-Reply-To: <20081112213920.GB5018@sun.com> Fedor Sergeev writes: > Please, correct me if I'm wrong: > > - by default rebase uses "simplified" merge, which (roughly speaking) > simply goes around patching parent with changes from either branches A and B > > - rebase -m applies 'recursive' merge (default merge strategy) which is > kind of smarter and determines a conflict in my case > > - literally the same happens when I do merge instead of rebase If "the same" means "always use 'recursive' merge, without 'am -3' (mis)behaviour seen in rebase", then yes. > - cherry-pick fails just because "patch B" can not apply to A and that is > literally why rebase started falling out to *some* merge first hand I do not know about this part. Rebase _conceptually_ does cherry-pick but uses a different implementation. > If the above is true then can you, please, answer the following questions: I'll answer the one that cannot be answered without knowing history. I suspect answers to your other questions are found in the doc set. > - does rebase perform simplified merge only because of speed considerations? Historical accident. Originally rebase was only "format-patch | am", i.e. lift a patch from the commits to be rebased, apply them in order. Later, "am -3" was invented that allows you to apply patches with fuzz by using 3-way merge at the content level, which was successfull and rebase was taught about using it.