Jeff King <peff@xxxxxxxx> writes: > This is expected. Format-patch omits merge commits entirely, as they > can't be formatted as a simple diff that can be applied. > > There are lots of ways to look at the diff of a merge. By default, `git > show` will show a combined diff, which omits hunks where one side was > taken verbatim, but otherwise shows what each side did. > > The diff shown in the link above is a diff against the first-parent > (which you can also get locally with `git show --first-parent 582cd91`). > One _could_ apply that diff onto the first parent to achieve the same > tree as the merge plus all of the commits that got merged in. But it > wouldn't make any sense to apply that (aside from conflict resolution, > it would be redundant with all of the commits that format-patch just > output!). Yes, a first-parent diff is something you could call "a simple diff that can be applied to represent a merge", and it is consistent with the expectations of those who are used to do a squash (pseudo-)merge. I agree with you that it does not make sense to apply such a patch as a patch, of course. In addition to be redundant, it would be an equivalent of doing a squash (psuedo-)merge, and loses the "up to this point the side branch has been merged, so future merges won't have to look beyond this point in the past" (sort of going back to the prehistoric subversion days that did not keep track of which changes have been merged).
