5 ms·
There was a change to gofmt in 1.10, too: https://golang.org/doc/go1.10#gofmt https://golang.org/doc/go1.10#gofmt """Note that these kinds of minor updates to
by mappu 8y ago
There was a change to gofmt in 1.10, too: https://golang.org/doc/go1.10#gofmt https://golang.org/doc/go1.10#gofmt
"""Note that these kinds of minor updates to gofmt are expected from time to time. In general, we recommend against building systems that check that source code matches the output of a specific version of gofmt. For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended."""
- kodablah 8y ago> For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended. As a frequent repo/commit spelunker, I'm gonna have to disagree here. It is better to have this changed all in one commit instead of tacking on that formatting change along with an unrelated change elsewhere in the file and doing that all over the place at separate times. What's inherently fragile (formatting wise) is making a change to a file that does not meet the current formatting requirements and then having it format on save/commit, messing up blames, code review diffs, etc.
- iainmerrick 8y agoYep -- formatting for style is great iff it’s done rigorously and consistently on every commit (which is what a presubmit check is good for). Ad-hoc reformatting mingled in with real changes plays havoc with change tracking. Ideally the format would never change at all. An occasional change-the-world update is a reasonable compromise, but it should be done as a single commit with no logic changes.