The user needs to decide what to do next; the user may choose to do "git merge A C ; git merge B" instead,
but *after* inspecting the situation.
I find a few of the applied conflict markers strange after my inspection.
1. They suggest to choose one of the involved changes. But how do you think
about the situation if I found that the right resolution is to delete the
conflict section completely?
Why was the merging process not able to come to the same conclusion
automatically?
2. My tenth patch would like to delete six consecutive lines in a source file in
a way similar to the following example.
-drop 1 ...;
-drop 2 ...;
-drop 3 ...;
-drop 4 ...;
-
-
void make_parser()
elfring@Sonne:~/Projekte/BtYacc/lokal2> git merge --stat --verbose -m 'Deletion
of duplicated function declarations' double_declaration_deletion
Auto-merging
mkpar.c
CONFLICT (content): Merge conflict in mkpar.c
Automatic merge failed; fix conflicts and then commit the result.
But the Git GUI displays this conflict like the following.
<<<<<<< HEAD
+drop 1 ...;
+drop 2 ...;
+drop 3 ...;
+drop 4 ...;
+
+static void find_final_state(void)
=======
+ void make_parser()
+ {
...
+ }
+
+ void find_final_state()
>>>>>>> double_declaration_deletion
I find three details suspicious here.
- Why are these lines marked for addition again?
- Why is the function "find_final_state" referenced? (Does this indicate an
off-by-one error in the first block?)
- Why are those parts like make_parser() not omitted that were moved to
different places in this source file by a previous patch?
I would appreciate your advices.
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html