On Tue, Aug 15, 2017 at 10:34 AM, Brandon Williams <bmwill@xxxxxxxxxx> wrote: > On 08/15, Ben Peart wrote: >> >> >> On 8/14/2017 5:30 PM, Brandon Williams wrote: >> >Add a '.clang-format' file which outlines the git project's coding >> >style. This can be used with clang-format to auto-format .c and .h >> >files to conform with git's style. >> > >> >Signed-off-by: Brandon Williams <bmwill@xxxxxxxxxx> >> >--- >> > .clang-format | 165 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> > 1 file changed, 165 insertions(+) >> > create mode 100644 .clang-format >> > >> >> I applied this and then ran: >> clang-format -i -style file *.c *.h builtin/*.c >> >> The modified files generate lots of line ending warnings. >> Apparently clang-format isn't respecting the git settings for line >> endings as it converted CRLF to LF in all the files it edited. >> >> $ git add . >> warning: LF will be replaced by CRLF in alloc.c. >> The file will have its original line endings in your working directory. >> warning: LF will be replaced by CRLF in base85.c. >> The file will have its original line endings in your working directory. >> warning: LF will be replaced by CRLF in bisect.h. >> [...] >> This sounds as if core.safecrlf is set to "warn" (by default?), you could set it to false to not have these warnings. However that is side stepping the problem of clang-format producing non-crlf line endings. Maybe the workflow can be setup such that this side stepping is ok, and no harm is done by the LF line endings by the formatting (If the formatting was a pre-commit hook, then Git would convert LF/CRLF and there would be no impact to your workflow I'd imagine).
