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

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

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.