Switch to using `git-clang-format` for `make format` #165
Conversation
|
the issue we had with #164 shouldn't really happen - as part of 3.0 PR i ran clang on all files (b2c8d16 and dc71c46 commits), precisely because there were several files that accumulated unformatted code over time. i have a feeling i didn't do it properly though, because i had to do it manually (since i'm on windows). likely it didn't use the proper there is no way to prevent affecting blame though.. if code needs to be formatted we can't do it in a way that doesn't affect the history. i think it's more important to stay on top of it. but i think it's good to have specific make targets that will only format what was changed, and then we can do periodical formatting for anything that lapses. we should also update |
|
Added a note about I'll merge in a few days assuming no objections |
|
FYI I'm pretty sure I can modify the Any interest? |
|
sounds like a good idea! |
|
I think this is now rebased and merged. But GitHub is having a bad day. So the PR didn't close. Will have another look in 24hrs and either merge again, or just close the PR. |
What does this PR do?
This PR updates the
make formattarget usegit-clang-format, which has been set to format only staged and unstaged changes, instead of formatting all the code in the repo.This should avoid issues like in #164 where new users end up formatting lots of old code, and also stop the
blameview getting messed up. However it does mean thatmake formatneeds to be run each commit (which it should be anyway).There is a
make format-allcommand that has the old behaviour, I expect we'll need to run this occasional to pick up any missing changes.I'm not 100% certain this is better than how we do it currently, but I think it is. Thoughts?
How should this be manually tested?
Run
make formatandmake format-allI have,