Tom Wijsman wrote:
> > > No, just a line in my vimrc that removes trailing whitespace.
> > 
> > You should probably disable it or remove trailing whitespaces in a
> > separate commit though.

I agree strongly with this.


> > Having functional changes mixed with whitespace/cosmetics in a
> > single commit makes it hard to read and understand.
> 
> 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?

In the ideal case, there should never be any whitespace changes in a
repository history. But we programmers frequently prove ourselves
unable to accomplish anything ideal, and whitespace is no exception.

Writing good code takes experience and awareness, and many if not
most are just interested in banging out something that works.

Since we have to live with whitespace changes, because someone
put broken whitespace into the repo before we got here, we should
at least make an effort to minimize the impact, and the best way is
to make them a separate commit.

That also helps significantly when using some of the nontrivial
functionality in Git, and while it could be argued that portage
isn't using Git yet it is anyway not a bad idea to get into habits
which support the most efficient and powerful use of Git for when
portage has migrated.

And of course the same applies to all repositories - so the good
habits mean immediate advantages in other repos where Git is already
being used.

Specifically, interactive rebase on its own or combined with
bisecting become a lot easier and quicker with clean commits.

I know people who are amazing in many ways but who fail to recgonize
those benefits. I'm not yet sure why that is and I fear that they
have some cognitive bias against Git. Try not to be that person,
because it doesn't help anyone. If something becomes easier by using
a particular process or workflow, then I think that's a good reason
to do it.


//Peter