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

[Junio C Hamano <gitster@pobox.com>]

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

> On 05/16/2012 07:49 PM, Junio C Hamano wrote:
> 
>> I am not fundamentally opposed to the idea of (optionally) detecting and
>> selectively dropping parts of a patch to an entire file or even hunks that
>> have already applied, but it needs to have a way remind the user somewhere
>> in the workflow that it did so and the log message may no longer describe
>> what the change does.  Most likely it would have to be done when producing
>> format-patch output, but an approach to make it a responsibility to notice
>> and fix the resulting log message to the person who applies the output, I
>> would imagine.
>
> Yep agreed, it would have to be optional.
> Maybe --ignore-duplicate-changes ?
>
> Appending a marker to the commit message of the adjusted patch would make sense,
> similar to how a 'Conflicts:' list is auto generated for commit messages.

These existing "conflicts:" are offered when recording manual resolutions
of a conflicting merge, and the user is actively thrown into an editor
when running "git commit" to record the result.

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.