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?
