Junio C Hamano <gitster@xxxxxxxxx> writes: > Justin Tobler <jltobler@xxxxxxxxx> writes: > >> On 24/10/09 05:55AM, Karthik Nayak wrote: >>> The current value for the column limit is set to 80. While this is as >>> expected, we often prefer readability over this strict limit. This means >>> it is common to find code which extends over 80 characters. So let's >>> change the column limit to be 0 instead. This ensures that the formatter >>> doesn't complain about code strictly not following the column limit. >> >> The column limit does lead to quite a few false positives. At the same >> time though, in some ways having a tool point out all the instances it >> occurs does make it easier to review if any should be addressed. >> >> If the goal is to have a CI job that we generally expect to pass, then >> it makes sense to remove it. I don't feel super strongly either way. > Is it possible for gatekeeper jobs to complain only on newly added > violations? The CI job is indeed only checking the newly added code. We do this using 'git clang-format' which takes in the basecommit as a param. This is in 'ci/run-style-check.sh'. > Then it is fine to have a limit with a bit of slack, > say like 96 columns (with 16-column readability slack). This is a good idea. Let me add change this in the next version.
Attachment:
signature.asc
Description: PGP signature
