Re: Do not raise conflict when a code in a patch was already added

[Johannes Sixt <j6t@kdbg.org>]

Am 20.08.2018 um 19:40 schrieb Phillip Wood:
> On 20/08/2018 11:22, Konstantin Kharlamov wrote:
>> It's spectacular, that content of one of inserted conflict markers is
>> empty, so all you have to do is to remove the markers, and use `git add`
>> on the file, and then `git rebase --continue`
>>
>> Its a lot of unncessary actions, git could just figure that the code it
>> sees in the patch is already there, being a part of another commit.
> 
> If there are conflict markers where one side is empty it means that some
> lines from the merge base (which for a rebase is the parent of the
> commit being picked) have been deleted on one side and modified on the
> other. Git cannot know if you want to use the deleted version or the
> modified version.

There's another possibility (and I think it is what happens actually in 
Konstantin's case): When one side added lines 1 2 and the other side 
added 1 2 3, then the actual conflict is << 1 2 == 1 2 3 >>, but our 
merge code is able to move the identical part out of the conflicted 
section: 1 2 << == 3 >>. But this is just a courtesy for the user; the 
real conflict is the original one. Without this optimization, the work 
to resolve the conflict would be slightly more arduous.

-- Hannes