5 ms·
This is a dangerous feature for git repository hosts like GitHub to support. It makes it all too easy for subtle vulnerabilities to be introduced and omitted fr
by cassonmars 5y ago
This is a dangerous feature for git repository hosts like GitHub to support. It makes it all too easy for subtle vulnerabilities to be introduced and omitted from visible blame history, with reviewers presuming trust based on historic content. Example: codebase went through an audit, was approved, then someone sneaks in some subtle changes to some files under the guise of a bulk change, adds the commit to the ignore list, continues making more commits to other files. Pulling a report to see historic changes could result in the file made vulnerable being skipped because it appeared to occur before the last audit. Hard pass.
- AceJohnny2 5y agoMeh. In such a case, you'll find that the older code (skipping the bulk change commit) does not have the (mis)feature you're looking for, and you'll have to go the extra step of looking through the ignored commits. It makes the case of finding changes in some commits a bit harder (but not hard), in exchange for reducing the noise from those same commits. Having been long hampered by ugly codebases that I didn't dare touch for fear of "blame" poisoning, I think this is a net positive overall.
- AceJohnny2 5y agoI actually encountered a similar situation years ago, where I tried to bisect for a regression. Problem was, old code wasn't testable for my regression, and I had to apply a patch to it to be able to automatically test it. I kept getting nonsensical results out of the bisect however. I later realized that my patch to make old code testable introduced the very regression I was looking for!
- lilyball 5y ago`git blame` is not the tool you use to see if a file changed. It’s the tool you use to view per-line changes. If you want to see historic changes you just view the log, which is unaffected by this.
- leriksen 5y agoThat's not a problem caused by git, it's a problem caused by undisciplined developers.
- aitchnyu 5y agoBlack for Python compares the AST before and after formatting as an additional measure. Linters could ship with an option to verify if two inputs (past and current version of file) are same in behavior but different in formatting, import order etc.
- jakub_g 5y agoSimple solution: whenever a rev is skipped, add a UI warning somewhere: "3 revisions were skipped due to ignore-rev file"