Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.48 as permitted sender)
	client-ip=209.85.214.48; envelope-from=mh.in.england@gmail.com;
	helo=mail-bk0-f48.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <3552695.aET6a1zFq8@momentum>
References: <CANEZrP1Sd8cK2YUr4OSvnOxEJrbWpmfdpor-qbap1f98tGqPwg@mail.gmail.com>
	<3552695.aET6a1zFq8@momentum>
Date: Fri, 4 Oct 2013 13:32:47 +0200
Message-ID: <CANEZrP1-4vP10w6_Yg3tXAKcMh406rw2bsAnvML2WoaU5SUjYw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: multipart/alternative; boundary=20cf30223bf567533904e7e8a97e
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Code review
Precedence: list

--20cf30223bf567533904e7e8a97e
Content-Type: text/plain; charset=UTF-8

> There is more to a git branch than just the overall difference.  Every
> single
> log message and diff is individually valuable.


When the log messages don't accurately describe the contents of the diff,
it's just misinformation and noise. Everyone starts out by wanting a neat
collection of easy to understand and review commits, but in practice it's
extremely hard to always get it.

I know how to make squashed commits, thanks. I've done LOTS of code review
in my life. I'm making a point here as one of the few people who goes
through large pull requests and reviews them line by line. It's hard,
partly because github sucks, and partly because reviewing lots of small
commits sucks.

There's nothing that makes a single large commit harder to review. It's the
same amount of code or strictly less, given the tendency for later commits
to change earlier ones. You can easily search the entire change whilst
reviewing. There are lots of things that make it easier.

FWIW inside Google the code review process is one-commit-one-review.

--20cf30223bf567533904e7e8a97e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"=
color:rgb(34,34,34)">There is more to a git branch than just the overall di=
fference. =C2=A0Every single</span><br>
</div>
log message and diff is individually valuable.</blockquote><div><br></div><=
div>When the log messages don&#39;t accurately describe the contents of the=
 diff, it&#39;s just misinformation and noise. Everyone starts out by wanti=
ng a neat collection of easy to understand and review commits, but in pract=
ice it&#39;s extremely hard to always get it.</div>
<div><br></div><div>I know how to make squashed commits, thanks. I&#39;ve d=
one LOTS of code review in my life. I&#39;m making a point here as one of t=
he few people who goes through large pull requests and reviews them line by=
 line. It&#39;s hard, partly because github sucks, and partly because revie=
wing lots of small commits sucks.</div>
<div><br></div><div>There&#39;s nothing that makes a single large commit ha=
rder to review. It&#39;s the same amount of code or strictly less, given th=
e tendency for later commits to change earlier ones. You can easily search =
the entire change whilst reviewing. There are lots of things that make it e=
asier.</div>
<div><br></div><div>FWIW inside Google the code review process is one-commi=
t-one-review.</div></div></div></div>

--20cf30223bf567533904e7e8a97e--