Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:50

Pádraig Brady [off-list ref] writes:
On 05/16/2012 08:12 PM, Junio C Hamano wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help