Abhilash Raj writes:
I don't see the tools actually supporting formatting only-diffs.
I don't know if git diff supports everything GNU diff does but --ignore-all-space would likely help quite a bit.
It shouldn't be that hard to write a blue-diff command for git:
- create a temporary branches at the relevant commits
- for each temporary branch 2.1 checkout the branch 2.2 run blue on the relevant .py files and commit
- diff the temparary branches and save the output
- delete the temporary branches
I don't know if this would help in practice, but the theory seems good.
Scripting that should be easy, and I can test it on the Postorius code. I'm not going to get to it before December, though, so if you want to do it first :-D
It _can_ be done by piping all the updated files to
bluecommand, but then reverting style changes in parts of file where there wasn't any real change made would be more work than just fixing the flake8 errors manually.
Is that necessary? Since the desired result is reformatted files without impairing the ability to diff, why would we revert the style changes?
I am trying to think if we can make that process better, after making a one-time code formatting change, through tooling or alternative commands to grok the diffs.
Additional tools to parse the diffs might be useful. Another possibility would be to diff the AST. :-O
Are you usually looking for just anything that looks odd or typically any kind of difference that looks suspicious or just trying to learn the differences?
Both of those are common. Typically it's something where I can't come up with a bisectable test, eg, a GUI regression. Then it's wait for rebuild, fire up the app, mess with the GUI, repeat ... so I don't actually bisect, once I have a bracket I just take that diff.
Can just comparing the commits/commit messages?
git diff --stat often helps isolate to a file.
or Merge Requests merged since the feature branch would help since we mandate all changes go through MR workflow?
I don't see how that helps if you're looking at a dozen commits touching that file on main.
I don't know if I can speak much about comparing raw diffs, because I very rarely end up doing that.
I try to avoid it, but about even in the large code bases I know best (XEmacs, Lisp and C) half the time I end up looking at diffs.
I am usually looking at commit level data and looking for MRs that last changed the point I am interested in with
git-blamefor some contextual data around the MR. Merge commits have the MR no to easily track where the change came from.
I rarely can pinpoint the relevant code without a diff, though. Most of the time the bad data is several frames up the stack, and was generated far from the visible error.
Also, you and I are likely to be working on code we just wrote or reviewed. We need to consider the drive-by contributor who is not going to know our code well.
Steve