From: Konstantin Kharlamov Date: Tue, 21 Aug 2018 09:37:54 GMT Subject: Re: Do not raise conflict when a code in a patch was already added Message-ID: In-Reply-To: <0d36d185-23d5-a656-67dd-5df86abed3e9@kdbg.org> 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?