Return to Question

We have a large Java project (1m+ SLOC) with mixed whitespace - some files have tabs and some have spaces. It's tricky to make my editor work with whichever file I happen to be editing.

We are going to choose a convention and enforce it in future. The question is whether I should make one commit to correct the whitespace in the whole project now.

Git can ignore changes in whitespace, so in future to compare with older revisions we would have to use git diff -w. However, if and when we update a file in a piecemeal way we would still have to use git diff -w.

For the record, this is an Eclipse RCP project, so using an IDE other than Eclipse is not really sensible.

We have a large Java project (1m+ SLOC) with mixed whitespace - some files have tabs and some have spaces. It's tricky to make my editor work with whichever file I happen to be editing.

We are going to choose a convention and enforce it in future. The question is whether I should make one commit to correct the whitespace in the whole project after the decision is made.

Git can ignore changes in whitespace, so in future to compare with older revisions we would have to use git diff -w. However, if and when we update a file in a piecemeal way we would still have to use git diff -w.

For the record, this is an Eclipse RCP project, so using an IDE other than Eclipse is not really sensible.

Edit: There are some good answers here, but they tend to discuss how I should go about this rather than whether this is a good idea or whether I should just leave well alone, which is what I'm really interested in.

We have a large Java project (1m+ SLOC) with mixed whitespace - some files have tabs and some have spaces. It's tricky to make my editor work with whichever file I happen to be editing.

We are going to choose a convention. The question is whether I should make one commit to correct the whitespace in the whole project now.

Git can ignore changes in whitespace, so in future to compare with older revisions we would have to use git diff -w. However, if and when we update a file in a piecemeal way we would still have to use git diff -w.

We have a large Java project (1m+ SLOC) with mixed whitespace - some files have tabs and some have spaces. It's tricky to make my editor work with whichever file I happen to be editing.

We are going to choose a convention and enforce it in future. The question is whether I should make one commit to correct the whitespace in the whole project now.

Git can ignore changes in whitespace, so in future to compare with older revisions we would have to use git diff -w. However, if and when we update a file in a piecemeal way we would still have to use git diff -w.

For the record, this is an Eclipse RCP project, so using an IDE other than Eclipse is not really sensible.

We have a large Java project (1m+ SLOC) with mixed whitespace - some files have tabs and some have spaces. It's tricky to make my editor work with whichever file I happen to be editing.

We are going to choose a convention. The question is whether I should make one commit to correct the whitespace in the whole project now.

Git can ignore changes in whitespace, so in future to compare with older revisions we would have to use git -w. However, if and when we update a file in a piecemeal way we would still have to use git -w.

We have a large Java project (1m+ SLOC) with mixed whitespace - some files have tabs and some have spaces. It's tricky to make my editor work with whichever file I happen to be editing.

We are going to choose a convention. The question is whether I should make one commit to correct the whitespace in the whole project now.

Git can ignore changes in whitespace, so in future to compare with older revisions we would have to use git diff -w. However, if and when we update a file in a piecemeal way we would still have to use git diff -w.