Bug 468551 - neighboring hunks automaticlly merge instead of conflict
Summary: neighboring hunks automaticlly merge instead of conflict
Status: NEW
Alias: None
Product: JGit
Classification: Technology
Component: JGit (show other bugs)
Version: 4.0   Edit
Hardware: PC Linux
: P3 critical with 3 votes (vote)
Target Milestone: ---   Edit
Assignee: Christian Halstrick CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-27 16:58 EDT by Shawn Pearce CLA
Modified: 2015-07-29 04:13 EDT (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Shawn Pearce CLA 2015-05-27 16:58:49 EDT 
ps2 of https://go-review.googlesource.com/6802 was incorrectly merged by JGit.

Take ps1 (e0175cd060) and cherry pick onto ps2's parent (bcf43e956538e3709428b5b0a07407dbfcd26135) using git-core. This creates a conflict because ps1 and the parent bcf43e9 both add text to the same switch statement at the same position in the file.

JGit blindly adds both blocks and does not fail.

git-core is taking the slightly safer approach by assuming a conflict is possible if both sides are inserting text at the exact same spot in the file.
Comment 1 Christian Halstrick CLA 2015-06-11 05:00:56 EDT 
I thought that we once introduced that some (3?, 1?) lines above and below a changed line could cause conflicts. I'll debug with the use-case you mentioned.
Comment 2 Christian Koppen CLA 2015-07-06 01:26:55 EDT 
This is a blocker. We currently evaluate EGit on Luna (JGit 3.7.1.20150426175-r) for a bigger project and found by accident that we suffered this bug. Now how can we be sure whether code after fast-forward merging resembles the developers' code?
Please look into it.