Hi, I do not care what bracing style we use. I do have a preferred one, but I don't care which one we use.
I hate that we have check style, but not a gofmt equivalent. I would take any amount of churn pain to have a gofmt equivalent so I could stop thinking about style. I would not want the churn between old and new versions of the code for just changing the bracing style. The win is nowhere near big enough. For a gofmt equivalent I would be on board for even a big bang because then we actually get something of value out of it. Maybe there is some clever way to not just reformat the tip, but reformat the entire history by reprocessing the git repo to minimize changes between branches, even older ones. Ariel On Sat, Jan 18, 2025, at 8:16 AM, Josh McKenzie wrote: > Trying to break out discussions here to keep things moving - see thread > "Checkstyle as style contract for Cassandra > <https://lists.apache.org/thread/8lzlc4x6g6yx766w738grxdcmqgwds7l>" > > One topic that came up on the thread was whether we were collectively happy > with our current newline bracing style and, if not, what we might do about > it. The following points came up: > 1. We would do this post-accord merging so as not to cause significant > rebase pains for the branch (unless active accord devs advocate for otherwise) > 2. re: git history pollution, Abe pointed out that we can use a > --ignore-revs-file option in git to switch bracing style in one go and keep > our history. > 3. Caleb advocated for limiting ourselves to trunk only. Given only bugfixes > go to older branches this would limit our surface area of change quite a bit. > 4. Mick seconded raised concerns about forks absorbing pain. We have > multiple fork owners on the thread in favor of making the change, but it's > worth keeping in mind. > In general, sentiment was clearly skewed towards changing our bracing style > on trunk to have braces on the same line as preceding control flow statement, > closing braces on newline. >
