Re: git format-patch doesn't exclude merged hunks

From: Junio C Hamano <gitster@pobox.com>
Date: May 16, 2012, 22:42 UTC
Message-ID: <7v4nrfd9yx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4FB40A7E.80705@draigBrady.com>

Pádraig Brady <P@draigBrady.com> writes:

Show 12 quoted lines

> On 05/16/2012 08:12 PM, Junio C Hamano wrote:
>> A patch that is reduced in a way you propose will apply to the receiving
>> tree cleanly without stopping, and does not offer an editor session to
>> adjust the log before making a commit.  "The user has a chance to notice
>> and correct" is not sufficient---nobody will spend extra effort to notice
>> let alone correct.  The reminder has to be a lot stronger than that, I
>> think, to cause the patch application to "fail" and require the user to
>> actively look at the situation.
>
> Yes it would make sense for `git am` to balk at such reduced patches,
> while allowing standard patch utilities to process the patches as
> normal.

That certainly is one way to implement it, but "am" may not necessarily be the best place to do so, depending on how you are using the output from format-patch. It does not matter if you are using "format-patch" piped to "am -3" as a more efficient way to cherry-pick or rebase commits, but if you are sending the result out to somebody else, you would instead want to sanitize the mess on your end, wouldn't you?

That would mean that "format-patch" needs to do more than just "mark a part of its output being suspicious". This is especially true as some people blindly send out format-patch output using the interface to "git send-email" without first verifying if the patches they are sending out is what they want to send out.