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:

1.  create a temporary branches at the relevant commits
2.  for each temporary branch
    2.1 checkout the branch
    2.2 run blue on the relevant .py files and commit
3.  diff the temparary branches and save the output
4.  delete the temporary branches

I don't know if this would help in practice, but the theory seems

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 `blue` command,
 > 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

 > 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-blame` for 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.

Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

Reply via email to