Fedor Sergeev <Fedor.Sergeev@Sun.COM> writes:

quoted text
> 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.

quoted text
>   - 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.

quoted text
> 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.

quoted text
>   - 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html