From 22612c04075b1bce61922e396cca4641760f226b Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Tue, 15 May 2012 22:04:03 +1000 Subject: [PATCH] merge: make some conflicts less conflicting. If a 'conflict' has an empty 'before' section, then it is probably to separate things - and insertion in the original (unmatched) and and insertion in the result. So split it into those two, but leave the result marked as a Conflict as the order of the insertions is not clear. For now this mostly affects -B which can display the conflict more effectively. Signed-off-by: NeilBrown --- merge2.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/merge2.c b/merge2.c index 96768fb..145ae24 100644 --- a/merge2.c +++ b/merge2.c @@ -422,6 +422,20 @@ struct ci make_merger(struct file af, struct file bf, struct file cf, if (ignore_already && check_alreadyapplied(af, cf, &rv.merger[i])) rv.ignored++; + else if (rv.merger[i].bl == 0 && + rv.merger[i].cl > 0) + /* As the 'before' stream is empty, this + * could look like Unmatched in the + * original, and an insertion in the + * diff. Reporting it like that is + * probably more useful that as a full + * conflict. + * Leave the type for the insertion as + * Conflict (not Changed) as there is some + * real uncertainty here, but allow the + * original to become Unmatched. + */ + rv.merger[i].al = 0; } a += rv.merger[i].al; b += rv.merger[i].bl; -- 2.39.5