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

From: Johannes Sixt <j6t@kdbg.org>
Date: Aug 20, 2018, 19:22 UTC
Message-ID: <0d36d185-23d5-a656-67dd-5df86abed3e9@kdbg.org>
In-Reply-To: <ab5021a9-6980-b96c-9d51-cc301844f2af@talktalk.net>

Am 20.08.2018 um 19:40 schrieb Phillip Wood:

Show 13 quoted lines

> 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