git format-patch doesn't exclude merged hunks

> Pádraig Brady <P@draigBrady.com> writes:
> 
>> For reference the two commits in question are:
>> https://github.com/openstack/nova/commit/7028d66
>> https://github.com/openstack/nova/commit/26dc6b7
>> Notice how both make the same change to Authors.
> 
> If you compare the changes these two commits introduce, you will also
> notice that the "Authors" file is the _only_ common part of them.
> 
> "format-patch" (more precicely, the "git cherry" machinery that identifies
> the same patch) does not _selectively_ drop only a part of a patch while
> keeping the other parts.  It is not per "hunk", it is not even per "file".
> 
> This is very much on purpose, and I think it is a good design decision.
> 
> In this particular case, the behaviour does look suboptimal, but if you
> think about it harder, you will realize that the perception comes largely
> because in this particular commit, the change to the "Authors" file is the
> least interesting part of the change.
> 
> Imagine a case where you were replaying a commit that changes a file
> significantly and also changes another file in a trivial way, and where it
> were the significant change that has already been applied to the receiving
> codebase, not the insignificant change to "Authors" file.
> 
> Now imagine that format-patch dropped the part that brings in the
> significant change as duplicate, and replayed only the insignificant part.
> Most likely, the log message of the original commit explains what issue
> that significant change tried to solve, and how the implementation in the
> patch was determined to be an acceptable approach to solve it, and that is
> what you will be recording for the replayed commit that only introduces
> the remaining insignificant change.
> 
> 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.

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

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

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