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
pgpIogALwQqs4.pgp
Description: PGP signature
