git format-patch doesn't exclude merged hunks

git format-patch doesn't exclude merged hunks

[Pádraig Brady]

So I was using `git format-patch` to generate patches for
consumption by patch (as part of an RPM build),
and one of the patches was failing as part of it was
already applied.

It seems like format-patch should exclude bits it's
merge previously, at least as an option.

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.

cheers,
Pádraig.

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

[Junio C Hamano]

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.

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

[Pádraig Brady]

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

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.

cheers,
Pádraig.

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

[Junio C Hamano]

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.

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

[Pádraig Brady]

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.

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

[Junio C Hamano]

Pádraig Brady <P@draigBrady.com> writes:

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

That certainly is one way to implement it, but "am" may not necessarily be
the best place to do so, depending on how you are using the output from
format-patch.  It does not matter if you are using "format-patch" piped to
"am -3" as a more efficient way to cherry-pick or rebase commits, but if
you are sending the result out to somebody else, you would instead want to
sanitize the mess on your end, wouldn't you?

That would mean that "format-patch" needs to do more than just "mark a
part of its output being suspicious".  This is especially true as some
people blindly send out format-patch output using the interface to "git
send-email" without first verifying if the patches they are sending out is
what they want to send out.