git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: How to create patches for a merge?

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 18, 2010, 18:10 UTC
Message-ID
<7veikifm9m.fsf@alter.siamese.dyndns.org>
In-Reply-To
<83d7aaa41002180340p2f9b7241h9c220b84ec5dd1d@mail.gmail.com>
Geoffrey Lee <geoffreyj.lee@gmail.com> writes:
> This produces a merge conflict. In this scenario, "git format-patch
> master..bar" only produces 3 patches, omitting "Commit M". How do I
> deal with this?

There is no provision for communicating how a conflict is resolved over patches. The answer to your "How do I deal with *this*" question would be "It is up to you.", if your "*this*" is "I want to communicate this as a patch". The steps to deal with "*this*" may go like this:

 - Think what shape of patch you want to see in order to convey what
   "Commit M" did to the recipient of your patch series.  First, try to
   construct it, by hand if necessary, as a design of such a feature.
 - How would a recipient "apply" such a patch?  As commonly used "patch"
   implementations, including "git apply", may not be able to read the
   above format, and they would certainly not create a merge commit, so
   you need to design the recieving side as well.
 - Then implement them ;-)
The best I think of offhand to reproduce
     B---M---D
    /   /
   A---C
might go like this:
 (1) Emit diff between (A,B) as usual;
 (2) Emit diff between (A,C) as usual, but with additional information
     usually not found in regular patches to help recipient that this
     should be applied to the same commit as (1) is applied to;
 (3) Emit diff between (B,M) and (C,M), but make sure that they won't be
     seen as a patch to be applied by ordinary "patch" programs to avoid
     mistakes at the recipient side.  Include some way to tell the
     recipient that these two "patches" need to be applied to the results
     of applying (1) and (2), and that the result needs to be recorded as
     a merge between them.
 (4) Emit D as usual;

Then the recipient would start from something that resembles A (call it X) and do the following:

 (5) Apply (1); call that result B'
       B'
      /
     X
 (6) Apply (2), following that additional insn to apply the patch to the
     base of (5); call that result C'
       B'
      /
     X---C'
 (7) Apply (B,M) half of (3) to B' and call it M'
       B'..M'
      /
     X---C'
 (8) Apply (C,M) half of (3) to C' and call it M"
       B'--M' M"
      /      .
     X------C'
 (9) If M' and M" do not match (which can happen when A and X are majorly
     different), merge them using X as their common ancestor, and resolve
     conflicts as necessary, and call the result M'".
     If M' and M" do match, be happy and call either of them M'".
         B'..M'..M'"                B'..M'"
        /       .       or         /   . 
       /       M"                 X---C'
      /       .
     X-------C'
 (10) Record M'" as children of B' and C'.
       B'--M'"
      /   /
     X---C'
 (11) Apply (4); call that result D'
        B'--M'"-D'
      /   /
     X---C'
and you are done.
Previous: Geoffrey LeeNext: Jeff King
Message 2 of 5 in “How to create patches for a merge?”
  1. Geoffrey LeeFeb 18, 2010
  2. Junio C HamanoFeb 18, 2010
  3. Jeff KingFeb 18, 2010
  4. Geoffrey LeeFeb 19, 2010
  5. Clemens BuchacherFeb 20, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.