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

From: Junio C Hamano <gitster@pobox.com>
Date: May 16, 2012, 18:49 UTC
Message-ID: <7vhavgc660.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4FB3CAE3.6040608@draigBrady.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.