From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VS3cu-0002jt-NG for bitcoin-development@lists.sourceforge.net; Fri, 04 Oct 2013 11:32:56 +0000 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; Received: from mail-bk0-f48.google.com ([209.85.214.48]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VS3cr-0002bE-UC for bitcoin-development@lists.sourceforge.net; Fri, 04 Oct 2013 11:32:56 +0000 Received: by mail-bk0-f48.google.com with SMTP id my13so1464307bkb.35 for ; Fri, 04 Oct 2013 04:32:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.205.22.71 with SMTP id qv7mr12510787bkb.20.1380886367374; Fri, 04 Oct 2013 04:32:47 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.204.237.74 with HTTP; Fri, 4 Oct 2013 04:32:47 -0700 (PDT) In-Reply-To: <3552695.aET6a1zFq8@momentum> References: <3552695.aET6a1zFq8@momentum> Date: Fri, 4 Oct 2013 13:32:47 +0200 X-Google-Sender-Auth: yjwFgfMYODWSnX2XezPTe5QLATY Message-ID: From: Mike Hearn To: Andy Parkins Content-Type: multipart/alternative; boundary=20cf30223bf567533904e7e8a97e X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VS3cr-0002bE-UC Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Code review X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 11:32:56 -0000 --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

There is more to a git branch than just the overall di= fference. =C2=A0Every single
log message and diff is individually valuable.

<= div>When the log messages don't accurately describe the contents of the= diff, it'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's extremely hard to always get it.

I know how to make squashed commits, thanks. I've d= one LOTS of code review in my life. I'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's hard, partly because github sucks, and partly because revie= wing lots of small commits sucks.

There's nothing that makes a single large commit ha= rder to review. It'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.

FWIW inside Google the code review process is one-commi= t-one-review.
--20cf30223bf567533904e7e8a97e--