From: Markus Elfring <Markus.Elfring@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Challenges for an octopus merge
Date: Tue, 15 Feb 2011 18:29:26 +0100 [thread overview]
Message-ID: <4D5AB7F6.8040508@web.de> (raw)
In-Reply-To: <7vd3my1leq.fsf@alter.siamese.dyndns.org>
> 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
next prev parent reply other threads:[~2011-02-15 17:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-10 14:30 Challenges for an octopus merge Markus Elfring
2011-02-10 16:09 ` Junio C Hamano
2011-02-11 16:23 ` Markus Elfring
2011-02-11 18:22 ` Junio C Hamano
2011-02-12 4:50 ` Markus Elfring
2011-02-15 17:29 ` Markus Elfring [this message]
2011-04-08 15:27 ` Markus Elfring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D5AB7F6.8040508@web.de \
--to=markus.elfring@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.