6 ms·

FTA: "Reformatting the file (with indent, for example) makes diffs completely impossible since the whole file will be different." Apparently the author doesn't

FTA: "Reformatting the file (with indent, for example) makes diffs completely impossible since the whole file will be different." Apparently the author doesn't know about the -w option to diff, which makes it ignore whitespace.

jrockway 17y ago
If a well-known fact makes your argument weaker, you should always omit it. It makes your writing more credible!
wheels 17y ago
A better argument is that it makes [svn / git / cvs] [blame / annotate] useless, which it does.
- humbledrone 17y ago
  The -w option seems to do the same thing with "git blame" that it does with diff -- ignore whitespace changes.
  - deleted 17y ago
    [deleted]
JulianMorrison 17y ago
So you have a rule, "every file gets formatted in <style> before it gets checked in - edit in any style you please, but reformat it after".
- jrockway 17y ago
  Exactly. This is almost common sense; I have never specifically told anyone "to commit to my repository, make sure you indent in such-and-such way". I have also never been told this rule; if I notice that every indentation level is two spaces more than the last level, I assume I should do the same. (If it's a whole project, I just add the changed settings to my .eproject file, and never think about it again. Very simple.) I have found, in general, that it's the very new or very bad programmers that want to quibble over style. Everyone I've worked with is fine with anything. In the long run, it just doesn't matter at all.
  - __david__ 17y ago
    The rules is somewhat common sense. But I have had to tell people the rule (mostly to very new programmers). Interestingly I haven't found that they wanted to quibble about style, they just didn't notice they were doing things differently. Putting the correct thing in their .emacs usually clears things up (show-trailing-whitespace throws your loose whitespace habits right in your face).
- ubernostrum 17y ago
  Yeah, and most projects do -- it's called a style guide.
prodigal_erik 17y ago
Every version control system I've ever used would put a change to every line of the file in its history. It would be possible to retrieve all those changes and then filter out the ones that I don't care about, but that's so expensive that I've never seen it as a built-in feature.

jrockway 17y ago

If a well-known fact makes your argument weaker, you should always omit it. It makes your writing more credible!

wheels 17y ago

A better argument is that it makes [svn / git / cvs] [blame / annotate] useless, which it does.

humbledrone 17y ago
The -w option seems to do the same thing with "git blame" that it does with diff -- ignore whitespace changes.
- deleted 17y ago
  [deleted]

JulianMorrison 17y ago

So you have a rule, "every file gets formatted in <style> before it gets checked in - edit in any style you please, but reformat it after".

jrockway 17y ago
Exactly. This is almost common sense; I have never specifically told anyone "to commit to my repository, make sure you indent in such-and-such way". I have also never been told this rule; if I notice that every indentation level is two spaces more than the last level, I assume I should do the same. (If it's a whole project, I just add the changed settings to my .eproject file, and never think about it again. Very simple.) I have found, in general, that it's the very new or very bad programmers that want to quibble over style. Everyone I've worked with is fine with anything. In the long run, it just doesn't matter at all.
- __david__ 17y ago
  The rules is somewhat common sense. But I have had to tell people the rule (mostly to very new programmers). Interestingly I haven't found that they wanted to quibble about style, they just didn't notice they were doing things differently. Putting the correct thing in their .emacs usually clears things up (show-trailing-whitespace throws your loose whitespace habits right in your face).
ubernostrum 17y ago
Yeah, and most projects do -- it's called a style guide.

prodigal_erik 17y ago

Every version control system I've ever used would put a change to every line of the file in its history. It would be possible to retrieve all those changes and then filter out the ones that I don't care about, but that's so expensive that I've never seen it as a built-in feature.