Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
Attachment:
t.bun
Description: a bundle out of a sample repo
