Brian Cain <quic_bc...@quicinc.com> writes: > On 5/30/2024 6:23 AM, Alex Bennée wrote: >> It's a pain when you come back to a code base you haven't touched in a >> while and realise whatever indent settings you were using having >> carried over. Add an editorconfig and be done with it. >> >> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> > > > Adding an editorconfig seems like a great idea IMO. But I wonder - > will it result in unintentional additional changes when saving a file > that contains baseline non-conformance?
This is for the semihosting tests, we have had an editorconfig in the mainline QEMU repo for a long time. Generally it's just standardising what people usually hand configure their editors for which can range in their aggressiveness in reformatting existing code. > Related: would a .clang-format file also be useful? git-clang-format > can be used to apply formatting changes only on the code that's been > changed. As a pre-commit hook? Or via something like clangd? > Also: should we consider excluding any exceptional files that we don't > expect to conform? Do we have such files? We certainly have a bunch of legacy whitespace damage hanging about but I didn't think we had a lot of non-conforming files. <snip> -- Alex Bennée Virtualisation Tech Lead @ Linaro
