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

From: Junio C Hamano <gitster@pobox.com>
Date: May 16, 2012, 19:12 UTC
Message-ID: <7v8vgsc544.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4FB3FA59.1010707@draigBrady.com>

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

Show 16 quoted lines

> 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.