Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Git blame is very rarely the right tool for the job. Whoever last touched a file is kinda irrelevant in most cases.
Git bisect is usually a much better choice - it'll tell you exactly what commit broke things all by itself if you can script a test, and that's often hugely, hugely helpful.
It's also why you should always have small, incremental commits & PRs (especially if you squash PRs by default) - as small commits causing issues are way more helpful. We recently used this technique to find a bug in our code that turned out to be because of a minor library upgrade. Took all of half an hour to script and test, but it would've taken us days to track that down otherwise.
fuck what i have got myself into. git blame is a bitch.
I recently pushed a big change that is supposed to replace a library with another.
adding the library and custom classes as a seperate item was not an issue. however tech lead asked me to use it in some modules , as example. i took it as some "complete" modules and converted 2 of them with complete replacement of library.
What he actually meant (I presume) was converting only parts of those modules on which i have worked. i was not suppose to touch the parts that i haven't worked on, but i did anyway to make that cheesy "I replaced all instances of library x with library y" statement.
now fuck me hard. there were super hacks and buggy code in those modules which am definitely sure didn't break due to my changes. but on almost every line it shows my name when we open the git blame . ughh fuck
rant