All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.