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