[adrianmsmith]

Interesting. Yeah I did think maybe this could be solved by more tooling. But at my place it work it isn’t, at least at the moment. Perhaps I could change that.

Do you have any info on what I could use to make the command-line “git diff” and “git rebase” handle this style of formatting? Ideally so the latter merges and produces code which matches “gofmt” output?

On the other hand I suppose my point is that even if there were such tooling, using style of formatting doesn’t offer enough (any?) benefit to justify the effort of introducing the tooling.

[Juliate]

Context matters, but this what I would do (and I always apply when landing in a project, own or client, that has no documented or enforced code style):

1/ always have pre-commit hooks running lint/fmt, and document how to implement them in a common fashion in the team,

2/ strive to follow the language conventions (and if not, have those divergences explicitly defined in the linter/formatter tool configuration), this helps the team to align with it,

3/ having a job server-side that blocks merging PRs that do not pass both of these steps.

[adrianmsmith]

Thanks. We're doing all that.

But that doesn't help when you do "git rebase" and there's a large conflict which you have to resolve manually, caused by two people changing different lines, and one or both of those lines caused the formatting of the whole block to change. That's the source of my frustration.