We are sick of linting. So we want to use black in our project. Unfortunately, it changes almost every other line in our project which would make us loose most of our authorship information. We use annotate
in pycharm or git blame
a lot to figure out who to talk to when looking at specific code pieces. How could this information be preserved when changing lots of files in one commit?
Edit: As this is a duplicate of this question, I'd like to focus rather on a "as good as possible" approach.
Let's assume the lint commit is created by an artificial (but known) author, hence serving as a flag. Is it then possible to create a git blame
like output which shows all authors since this key lint commit as well as any previous author of lines that were changed in that commit?
I realize this wouldn't work well for lines that were split / merged but it at least gives a faster way to limit the scope of potential persons to talk to to 1,2,3 people.
The git blame command is used to examine the contents of a file line by line and see when each line was last modified and who the author of the modifications was.
In case you don't know git-blame If you want to know who last changed a particular chunk of code, you use Git to run a special command. That command is called blame. In other words, you don't ask who the author is, you ask who's to blame for a particular contribution.
to think or say that someone or something is responsible for something bad blame somebody/something (for something) She doesn't blame anyone for her father's death. A dropped cigarette is being blamed for the fire. blame something on somebody/something Police are blaming the accident on dangerous driving.
From https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt:
--ignore-rev
Ignore changes made by the revision when assigning blame, as if the change never happened. Lines that were changed or added by an ignored commit will be blamed on the previous commit that changed that line or nearby lines. This option may be specified multiple times to ignore more than one revision. If the blame.markIgnoredLines config option is set, then lines that were changed by an ignored commit and attributed to another commit will be marked with a ? in the blame output. If the blame.markUnblamableLines config option is set, then those lines touched by an ignored commit that we could not attribute to another revision are marked with a *.
If the code formatting is all done in a single commit, I think you could use that flag. There's also a --ignore-revs-file
that looks useful if you want to ignore more than a single commit.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With