Re: overly smart rebase - bug or feature?

From: Fedor Sergeev <fedor.sergeev@sun.com>
Date: Nov 12, 2008, 21:39 UTC
Message-ID: <20081112213920.GB5018@sun.com>
In-Reply-To: <7vod0n41i5.fsf@gitster.siamese.dyndns.org>

On Mon, Nov 10, 2008, Junio C Hamano wrote:

Show 13 quoted lines

> Fedor Sergeev <Fedor.Sergeev@Sun.COM> writes:
> >> You might be able to work this around by forcing rebase not to use the
> >> simplified 3-way merge, by saying "rebase -m".
> >
> > Yeah, it worked.
> > ...
> > CONFLICT (delete/modify): Makefile deleted in master and modified in HEAD~0. Version HEAD~0 of Makefile left in tree.
> > ...
> >
> > Though it does make me wonder why *simplified* 3-way merge is smarter than git merge ;)))
> 
> Simplified one is not _smarter_.  It is merely _faster_, exactly because
> it only looks at the paths between A^..A and nothing else.

I seem to start getting grasp on it.
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

  - 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

If the above is true then can you, please, answer the following questions:
  - is there any merge strategy that can do "simplified" merge just like that in rebase?
    (not that I need it, but just for educational purpose)

  - does rebase perform simplified merge only because of speed considerations?
    (e.g. are there any correctness/usability issues with using smarter merge algo on rebase)

  - is there any .git/config variable that affects which merge to use upon rebase?

best regards,
  Fedor.