1 |
Tom Wijsman wrote: |
2 |
> > > You should just convert the commit diff to not include space |
3 |
> > > changes. |
4 |
> > |
5 |
> > Tom, I don't understand what you mean here? Who should do the convert |
6 |
> > and why? |
7 |
> |
8 |
> It's a human error for both ends, it can thus be done on both sides. |
9 |
|
10 |
Hm, I'm not sure I follow. |
11 |
|
12 |
When a commit is created there's only one human involved; the person |
13 |
creating the commit. We should all try to avoid whitespace changes in |
14 |
all commits. |
15 |
|
16 |
Are you arguing that because people who happen to read commits and |
17 |
source code can provide options to hide whitespace changes in commits |
18 |
and/or use indent to always reformat source there is no point in |
19 |
avoiding whitespace changes (by getting formatting right the first |
20 |
time) and being strict about code style? |
21 |
|
22 |
|
23 |
> > Writing good code takes experience and awareness, and many if not |
24 |
> > most are just interested in banging out something that works. |
25 |
> |
26 |
> Good code ideally is tested. |
27 |
|
28 |
I see testing as orthogonal to writing code. |
29 |
|
30 |
The two can complement each other very nicely, but code can be good |
31 |
without testing, and testing does not reliably turn otherwise |
32 |
bad code into good. But testing can certainly preempt lots of both |
33 |
simple and advanced issues, like for example, broken whitespace. |
34 |
|
35 |
|
36 |
> > ... minimize the impact, and the best way is to ... |
37 |
> |
38 |
> Depends on whose impact you minimize, s/best/alternative/. |
39 |
|
40 |
I refer to the impact of whitespace changes (noise) in the repository |
41 |
on anyone and everyone who interacts with the repository in some way |
42 |
beyond usage. |
43 |
|
44 |
|
45 |
> > Specifically, interactive rebase on its own or combined with |
46 |
> > bisecting become a lot easier and quicker with clean commits. |
47 |
> |
48 |
> Rebasing is overkill in the Portage tree |
49 |
|
50 |
I don't think this can be said with certanity. Git allows new things |
51 |
which might lead to a situation where rebasing simply makes sense. |
52 |
|
53 |
|
54 |
> and not needed; |
55 |
|
56 |
I don't know about that at all. |
57 |
|
58 |
|
59 |
> as for bisect, it makes it worse because you introduce extra |
60 |
> commits to bisect. |
61 |
|
62 |
The extra commit may mean one extra test cycle, but if tests are |
63 |
automated that doesn't matter much. The benefit is that the *other* |
64 |
commit can much more easily be moved around, as I wrote, rebasing |
65 |
combined with bisecting. |
66 |
|
67 |
|
68 |
In any case, I guess you aren't arguing that because some more |
69 |
advanced uses of Git are perhaps not immediately useful there is no |
70 |
point in clean code style? |
71 |
|
72 |
|
73 |
> > Try not to be that person, because it doesn't help anyone. |
74 |
> |
75 |
> I'm not rooting either side, |
76 |
|
77 |
Understood - I want to clarify that I did not get the impression that |
78 |
you were, the "Try not to be that person" was a very broad request to |
79 |
everyone listening. |
80 |
|
81 |
|
82 |
> I just hate the noise that occurs when neither side takes an effort |
83 |
> to fix it. |
84 |
|
85 |
Consider that commits in version control systems are immutable, so |
86 |
it's not really possible to "fix" things there. |
87 |
|
88 |
I think the only real fix is to avoid that whitespace errors are |
89 |
committed in the first place. |
90 |
|
91 |
|
92 |
//Peter |