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

[Konstantin Kharlamov <hi-angel@yandex.ru>]

On 20.08.2018 22:22, Johannes Sixt wrote:
> 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.

Yeah, thanks, that's what happens. And I'm wondering, is it really 
needed to raise a conflict there? Would it be worth to just apply the 
line "3", possibly with a warning or an interactive question to user 
(apply/raise) that identical parts were ignored?