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

["Pádraig Brady" <P@draigBrady.com>]

On 05/16/2012 08:12 PM, Junio C Hamano wrote:
> 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.

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.

cheers,
Pádraig.