Junio C Hamano <gitster@xxxxxxxxx> writes: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > >> Yeah, then in that case, we probably want to ship some sort of container >> and script that can do that. Our default Rust target is Debian stable, >> so that seems like a decent target if we need to pick a distro. It's >> also a very common distro used in containers, so it's widely available >> to contributors using container-based development environments. That sounds like the ideal solution. >> I still think that if we're going to have this functionality and expect >> it to be used, we need to make it the default, build appropriate >> tooling, and check it in CI. If it's not fire-and-forget, people won't >> use it. > > There probably needs some balancing act, as I already pointed out, > what clang-format gives often do not make sense, and the point is > that they are not about styles (where we can safely say "no style is > liked by everybody") but about how readable the result is (which > sometimes is subjective but more often it is not). Until the tool > and its configuration is polished enough, blindly applying the > result with fire-and-forget mentality will degrade the quality of > our codebase. Allow me to share an unpopular opinion. I think you either fully commit to a formatter, or you don't care about formatting at all. I realize that's probably overly strict for most people, but I've been working mostly in Golang for several years, and having a tool that formats code and it's output is unarguably the standard is a bliss. I think the only way we can stop bikeshedding about formatting, is by adopting clang-format and make it's output the golden standard. We might not like it's output (similar to many people do not like `gofmt`s output), but it's a standard. If we have to wait for clang-format to support all the configuration options we prefer, we will be having this conversation over and over again over time. I don't think that's worth it. Code formatting should be the job of an automated tool, not a person. It's annoying to have this back-and-forth in reviews because it's not following the standard _the Git project_ has set, while it would be a lot less friction to follow a standard that's set by _the formatting tool_. -- Cheers, Toon