Hey Tim, Sorry I wasn't clear in my message, I should have written that the doc needs to be updated only if you ever chose to add this formatting check. But as you stated, it would be a lot of work and commit noise for little benefit and I understand completely why you would not want to do that.
It's the kind of thing that benefit fresh projects. Best regards, ~Nicolas On 17 Dec, Tim Düsterhus wrote: > Nicolas, > > Am 17.12.20 um 15:53 schrieb Nicolas CARPi: > > To fail or not to fail. That is the question! :) > > > > I'd add to that the contributor documentation should be updated to add > > steps for having a clang-format (or any other formatter) as a git > > pre-hook. > > As someone who actually contributes to the C source code of HAProxy I > disagree. > > 1) The codebase is fairly old and already has formatting issues (Tabs > and Spaces mixed within single files). Initially running the > autoformatter will create merge / rebase conflicts all over the place. > 2) A few source code locations are intentionally manually formatted like > they are. Autoformatters tend to stomp over that, breaking this > intentional formatting, decreasing readability. > 3) Clearly the actual contributors are not unhappy with the current > situation, otherwise they would already have introduced such an > autoformatting. > 4) It would require contributors to set up that autoformatter (in the > correct version, with the correct config, etc.), creating work for a > small benefit. > > Best regards > Tim Düsterhus > > > I'm partial to failing the build (in CI) to avoid using further > > electricity if the first step (syntax) fails, as another commit fixing > > the syntax will likely come after. > > > > ~Nico > > > -- ~Nico
