Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Peter Stuge <peter@stuge.se>]

[-- Attachment #1: Type: text/plain, Size: 3015 bytes --]

Tom Wijsman wrote:
> > > You should just convert the commit diff to not include space
> > > changes.
> > 
> > Tom, I don't understand what you mean here? Who should do the convert
> > and why?
> 
> 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.
> 
> 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 ...
> 
> 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.
> 
> 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.
> 
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]