Re: [PATCH] Allow format-patch to create patches for merges

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 26, 2009, 18:33 UTC
Message-ID: <7v3af57w8x.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0901261604420.25749@intel-tinevez-2-302>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> - lack an explanation when this makes sense (format-patch is commonly used 
>   for mail-based patch queues, and only -m 1 would make sense there, and 
>   only if you run format-patch with --first-parent),

You do not necessarily want --first-parent.

Suppose you have this topology

         B---D---E
        /   /
   M---A---C

where M is 'master', and E is 'mine'.

The format-patch command ignores merges by default because you can get diff for A-M, B-A, C-A, E-D and serialize the resulting history without it, and this is often sufficient. When D merges with a conflict, or D is an evil merge, however, you will not be able to reproduce how D looked like on the receiving end. Your --first-parent would instead format the log message for A B D E with patch text of A-M, B-A, D-B and E-D.

But as a recipient of such a patch series, I'd much prefer to see the patch text and the log message of B and C themselves. I'd either apply them on top of A serially, or apply them on top of A to recreate the forked history the sender had and merge, to arrive at the state the sender had at D either way, resolving a potential conflict (either when applying C on top of B, or when merging between B and C), and apply E on top.

Getting a first parent diff that says "I merged random stuff here at D and here is the difference D-B", is much less useful and throws us back to dark ages of CVS/SVN merges, especially because C could be a long multi-patch sequence.

I am not happy about Nathan's output. I think "-m" output is a wrong thing to use in that it just lets D-B and D-C patches in the same output file, without marking that it is something you should not be applying as part of the series blindly. The patch is "If you reproduced my B and C with the patches so far, here is a hint to help you recreate the merged state D", and care must be taken to make sure both the tool and the user notice the situation. "git am", after you have applied B and then C, will notice that the patches for D does not apply anyway, but the message should tell the recipient that it is _expected_ not to apply to avoid confusion. One possible solution might be to always show --cc patch in such a case, which (1) won't apply with patch nor git-am, and (2) will be clear it is not a patch by having more than two @@ signs on each hunk header.

If you really want to generate a patch for a merge commit (e.g. D in the above picture), what you may want is "here is a fix-up you need to apply on top of the result of naturally merging B and C to arrive at D". It could be empty if the merge is conflict-free and there is no evil amend.

Here is a food-for-thought sample history for interested parties to experiment on.