4 ms·

Huh, a change to spacing in gofmt? Won’t that cause extra source control churn in a lot of projects?

by iainmerrick 8y ago

Cthulhu_ 8y ago
I like to think it's OK because gofmt reduces formatting churn overall.
- masklinn 8y ago
  In this specific case it doesn't do that: any time you add or remove a field from a structure, if it's one of the "extremes" gofmt might re-pad the entire thing, churning the entire structure.
  - eyko 8y ago
    I actually dislike the new heuristic as it becomes difficult to read `key: value` pair when value is, say, 20 white-spaces padded to the right. I remember having to turn on the "highlight current line" setting in my editor just to do that on some codebases.
    - iainmerrick 8y ago
      Whether you like or dislike it, I don’t understand why it’s changing at all. I thought the main point of gofmt (which I applaud) was to avoid wasting any time whatsoever over formatting issues. It seems counterproductive for the golden formatting spec to be a moving target.
cyphar 8y ago
It actually could cause bigger problems than that. Most Go projects I've seen have CI runs that check whether 'gofmt' complains -- and fail builds if they do. Ultimately though I don't really care all that much. Everyone will fix it in a few commands, and everything will be green again.
- iainmerrick 8y ago
  I care if it makes it harder to browse version history and see which changes were made when, and why.
  - cyphar 8y ago
    I don't think it would make it much harder if people just do all of the 'gofmt' changes in a single commit. After all, it's not like your entire codebase consists of such edge-cases, and if you hit a 'git blame' where the commit is a format change you can always just do 'git blame $THE_FORMATTING_REVISION^ $file'. I have to do this all the time when 'git blame -wM' doesn't give me what I want when looking at kernel changes.
iudsfyg8ysd98fg 8y ago
This is why you lock to a specific version of gofmt and let team upgrade in conjuction with reformatted source repo.

Huh, a change to spacing in gofmt? Won’t that cause extra source control churn in a lot of projects?

Cthulhu_ 8y ago

I like to think it's OK because gofmt reduces formatting churn overall.

masklinn 8y ago
In this specific case it doesn't do that: any time you add or remove a field from a structure, if it's one of the "extremes" gofmt might re-pad the entire thing, churning the entire structure.
- eyko 8y ago
  I actually dislike the new heuristic as it becomes difficult to read `key: value` pair when value is, say, 20 white-spaces padded to the right. I remember having to turn on the "highlight current line" setting in my editor just to do that on some codebases.
  - iainmerrick 8y ago
    Whether you like or dislike it, I don’t understand why it’s changing at all. I thought the main point of gofmt (which I applaud) was to avoid wasting any time whatsoever over formatting issues. It seems counterproductive for the golden formatting spec to be a moving target.

cyphar 8y ago

It actually could cause bigger problems than that. Most Go projects I've seen have CI runs that check whether 'gofmt' complains -- and fail builds if they do. Ultimately though I don't really care all that much. Everyone will fix it in a few commands, and everything will be green again.

iainmerrick 8y ago
I care if it makes it harder to browse version history and see which changes were made when, and why.
- cyphar 8y ago
  I don't think it would make it much harder if people just do all of the 'gofmt' changes in a single commit. After all, it's not like your entire codebase consists of such edge-cases, and if you hit a 'git blame' where the commit is a format change you can always just do 'git blame $THE_FORMATTING_REVISION^ $file'. I have to do this all the time when 'git blame -wM' doesn't give me what I want when looking at kernel changes.

iudsfyg8ysd98fg 8y ago

This is why you lock to a specific version of gofmt and let team upgrade in conjuction with reformatted source repo.