|
From: Nicholas N. <n.n...@gm...> - 2023-04-23 22:39:50
|
On Sun, 23 Apr 2023 at 03:25, Mark Wielaard <ma...@kl...> wrote: > > > > You can send up a .gitconfig for the project, so it'll work automatically > > for everyone. > > How? > We would have a file, called `.git-blame-ignore-revs` by convention. Here's an example that hides the auto-formatting/unformatting that Paul accidentally committed recently: # Accidental clang-format on a few files, 2023-04-22. > bf347551c99313a4af9c38bdeda9b946c9795945 > > # Undo the previous commit, 2023-04-22. > 76d6b4591a5a05e43e1a819bf630c0d8ee857a7e > I tested this out, it works well. Here is the vanilla blame for a couple of lines in `memcheck/mc_main.c` that were affected: 76d6b4591a (Paul Floyd 2023-04-22 16:29:27 +0200 60) static void > ocache_sarp_Set_Origins ( Addr, UWord, UInt ); /* fwds */ > 76d6b4591a (Paul Floyd 2023-04-22 16:29:27 +0200 61) static > void ocache_sarp_Clear_Origins ( Addr, UWord ); /* fwds */ > and here is the blame using the `.git-blame-ignore-revs` file: afebe61b37 (Nicholas Nethercote 2002-09-23 09:36:25 +0000 60) static void > ocache_sarp_Set_Origins ( Addr, UWord, UInt ); /* fwds */ > 4cae5c3ed5 (Julian Seward 2008-05-01 20:24:26 +0000 61) static > void ocache_sarp_Clear_Origins ( Addr, UWord ); /* fwds */ > To make that work seamlessly with `git blame` requires running `git config blame.ignoreRevsFile .git-blame-ignore-revs` once per cloned repository. That command could easily be put somewhere that will always run while building. Somewhere in `configure.ac` seems like a logical place though I'd be happy to hear suggestions otherwise. Firefox's `.git-blame-ignore-revs` file is here: https://searchfox.org/mozilla-central/source/.git-blame-ignore-revs. It has hundreds of entries! I expect/hope we wouldn't need anything like that many, but it shows that the solution scales nicely to very large codebases. The end result is that the effect of auto-formatting on history can be worked around in a straightforward manner. (BTW, we could take advantage of `configure.ac` to set up other git aliases. E.g. we could have one for pushing to a try branch, so you just have to run `git vgtry $BRANCH` instead of `git push origin $BRANCH:users/$USERNAME/try-$BRANCH`.) I can see how it would work nicely for new python code. gdb also uses > python black (plus a buildbot checker) to auto-format their python > code. If you like we could add the same to the buildbot for valgrind. > Sounds great. I am all for automating this kind of thing, making it impossible to forget to do it or do it incorrectly. How exactly would it work? Would it be a post-commit check? Could we get the same check to run locally, to run pre-commit? > BTW. Trying the various formatters listed in auxprogs/pybuild.sh gives > me (pylint suggests to use a range generator instead of an array, then > black reformates the file to get everything on one line: > > - min_ofl_st_mtime_ns = min( > - [os.stat(ofl).st_mtime_ns for ofl in ofls] > - ) > + min_ofl_st_mtime_ns = min(os.stat(ofl).st_mtime_ns > for ofl in ofls) Interesting. I have black 22.6.0, what version do you have? Nick |