On Mon, Nov 10, 2008, Junio C Hamano wrote:
> Fedor Sergeev <Fedor.Sergeev@xxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
