Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

From
Junio C Hamano <hidden>
Date
2016-08-09 17:25:43
Johannes Schindelin [off-list ref] writes:
On Mon, 8 Aug 2016, Junio C Hamano wrote:
quoted
Unless a patch is about an area you are super familiar with so that you
know what is beyond the context of the patch to be able to judge if the
change is good in the context of the file being touched, it is always
hard to review from inside a mail reader.

Running "git am" is a good first step to review such a patch, as that
lets you view the resulting code with the full power of Git.  As you
gain experience on the codebase, you'll be able to spot more problems
while in your mail reader.
I am glad that you agree that the requirement to manually transform the
patches back into Git (where they had been originally to begin with) is
cumbersome. This is the first time that I see you admit it ;-)
I was about to apologize for writing a statement that can be
misread, but I do not think what I wrote can be misinterpreted, even
if a reader deliberately tries to twist the words s/he reads, to
lead to such a conclusion, so I won't.

I merely said that reviewing a change in an unfamiliar area is
harder (not "cumbersome", but "needs understanding first") with a
patch, and it is easier to see changes in context by applying (which
is an easy, not "cumbersome", process).
Thread (1 message) 1 message, 1 author, last reply 2016-08-09
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help