| 1 |
Tom Wijsman wrote: |
| 2 |
> > > No, just a line in my vimrc that removes trailing whitespace. |
| 3 |
> > |
| 4 |
> > You should probably disable it or remove trailing whitespaces in a |
| 5 |
> > separate commit though. |
| 6 |
|
| 7 |
I agree strongly with this. |
| 8 |
|
| 9 |
|
| 10 |
> > Having functional changes mixed with whitespace/cosmetics in a |
| 11 |
> > single commit makes it hard to read and understand. |
| 12 |
> |
| 13 |
> You should just convert the commit diff to not include space changes. |
| 14 |
|
| 15 |
Tom, I don't understand what you mean here? Who should do the convert |
| 16 |
and why? |
| 17 |
|
| 18 |
In the ideal case, there should never be any whitespace changes in a |
| 19 |
repository history. But we programmers frequently prove ourselves |
| 20 |
unable to accomplish anything ideal, and whitespace is no exception. |
| 21 |
|
| 22 |
Writing good code takes experience and awareness, and many if not |
| 23 |
most are just interested in banging out something that works. |
| 24 |
|
| 25 |
Since we have to live with whitespace changes, because someone |
| 26 |
put broken whitespace into the repo before we got here, we should |
| 27 |
at least make an effort to minimize the impact, and the best way is |
| 28 |
to make them a separate commit. |
| 29 |
|
| 30 |
That also helps significantly when using some of the nontrivial |
| 31 |
functionality in Git, and while it could be argued that portage |
| 32 |
isn't using Git yet it is anyway not a bad idea to get into habits |
| 33 |
which support the most efficient and powerful use of Git for when |
| 34 |
portage has migrated. |
| 35 |
|
| 36 |
And of course the same applies to all repositories - so the good |
| 37 |
habits mean immediate advantages in other repos where Git is already |
| 38 |
being used. |
| 39 |
|
| 40 |
Specifically, interactive rebase on its own or combined with |
| 41 |
bisecting become a lot easier and quicker with clean commits. |
| 42 |
|
| 43 |
I know people who are amazing in many ways but who fail to recgonize |
| 44 |
those benefits. I'm not yet sure why that is and I fear that they |
| 45 |
have some cognitive bias against Git. Try not to be that person, |
| 46 |
because it doesn't help anyone. If something becomes easier by using |
| 47 |
a particular process or workflow, then I think that's a good reason |
| 48 |
to do it. |
| 49 |
|
| 50 |
|
| 51 |
//Peter |
Archives