Re: Do not raise conflict when a code in a patch was already added
- From
- Konstantin Kharlamov <hi-angel@yandex.ru>
- Date
- Aug 21, 2018, 09:37 UTC
- Message-ID
- <e5f65c19-0f49-d48e-c600-7dfcd95f3218@yandex.ru>
- In-Reply-To
- <0d36d185-23d5-a656-67dd-5df86abed3e9@kdbg.org>
On 20.08.2018 22:22, Johannes Sixt wrote:
Show 22 quoted lines
> 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?