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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 9, 2016, 17:25 UTC
Message-ID: <xmqqlh05c0sj.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1608091339590.5786@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 15 quoted lines

> On Mon, 8 Aug 2016, Junio C Hamano wrote:
>
>> 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).