From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C0D621381F3 for ; Sun, 21 Apr 2013 18:47:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 509BAE0973; Sun, 21 Apr 2013 18:47:23 +0000 (UTC) Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) by pigeon.gentoo.org (Postfix) with ESMTP id 0ED43E094C for ; Sun, 21 Apr 2013 18:47:21 +0000 (UTC) Received: (qmail 18199 invoked by uid 501); 21 Apr 2013 18:47:17 -0000 Message-ID: <20130421184717.18198.qmail@stuge.se> Date: Sun, 21 Apr 2013 20:47:17 +0200 From: Peter Stuge To: gentoo-dev@lists.gentoo.org Subject: Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20130419091632.D01152171D@flycatcher.gentoo.org> <20130419153043.30ffc50c@portable> <20130421170549.41cfea49@portable> <20130421173226.2901a6fd@TOMWIJ-GENTOO> <20130421160042.3881.qmail@stuge.se> <20130421190709.105e02ae@TOMWIJ-GENTOO> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YV7D9JCVdz8QpFLW" Content-Disposition: inline In-Reply-To: <20130421190709.105e02ae@TOMWIJ-GENTOO> X-Archives-Salt: 2cb1d765-ed91-48c8-a23d-891beae5880a X-Archives-Hash: 7145e251e75b3d27a3f20291081eb3e8 --YV7D9JCVdz8QpFLW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tom Wijsman wrote: > > > You should just convert the commit diff to not include space > > > changes. > >=20 > > Tom, I don't understand what you mean here? Who should do the convert > > and why? >=20 > It's a human error for both ends, it can thus be done on both sides. Hm, I'm not sure I follow. When a commit is created there's only one human involved; the person creating the commit. We should all try to avoid whitespace changes in all commits. Are you arguing that because people who happen to read commits and source code can provide options to hide whitespace changes in commits and/or use indent to always reformat source there is no point in avoiding whitespace changes (by getting formatting right the first time) and being strict about code style? > > Writing good code takes experience and awareness, and many if not > > most are just interested in banging out something that works. >=20 > Good code ideally is tested. I see testing as orthogonal to writing code. The two can complement each other very nicely, but code can be good without testing, and testing does not reliably turn otherwise bad code into good. But testing can certainly preempt lots of both simple and advanced issues, like for example, broken whitespace. > > ... minimize the impact, and the best way is to ... >=20 > Depends on whose impact you minimize, s/best/alternative/. I refer to the impact of whitespace changes (noise) in the repository on anyone and everyone who interacts with the repository in some way beyond usage. > > Specifically, interactive rebase on its own or combined with > > bisecting become a lot easier and quicker with clean commits. >=20 > Rebasing is overkill in the Portage tree I don't think this can be said with certanity. Git allows new things which might lead to a situation where rebasing simply makes sense. > and not needed; I don't know about that at all. > as for bisect, it makes it worse because you introduce extra > commits to bisect. The extra commit may mean one extra test cycle, but if tests are automated that doesn't matter much. The benefit is that the *other* commit can much more easily be moved around, as I wrote, rebasing combined with bisecting. In any case, I guess you aren't arguing that because some more advanced uses of Git are perhaps not immediately useful there is no point in clean code style? > > Try not to be that person, because it doesn't help anyone. >=20 > I'm not rooting either side, Understood - I want to clarify that I did not get the impression that you were, the "Try not to be that person" was a very broad request to everyone listening. > I just hate the noise that occurs when neither side takes an effort > to fix it. Consider that commits in version control systems are immutable, so it's not really possible to "fix" things there. I think the only real fix is to avoid that whitespace errors are committed in the first place. //Peter --YV7D9JCVdz8QpFLW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFRdDQ0hR3Q0dhIfEgRAohbAKClhRfpAbOHcYzS1pH0D2X52mHCywCgnvlK byIxbfE42vmaLvuPDJj5lSk= =7E0W -----END PGP SIGNATURE----- --YV7D9JCVdz8QpFLW--