From: Johannes Sixt Date: Mon, 20 Aug 2018 19:22:46 GMT Subject: Re: Do not raise conflict when a code in a patch was already added Message-ID: <0d36d185-23d5-a656-67dd-5df86abed3e9@kdbg.org> In-Reply-To: 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