Re:What I wish I knew when I became CTO
by rhaps0dy on Thursday February 15, 2018 @09:18AM
(#16384116)
>Firing up git blame was next...
I like your story, but I find amusing that `git blame` has such an appropriate name.
Re:What I wish I knew when I became CTO
by murftown on Friday February 16, 2018 @09:19AM
(#16392456)
"git annotate" does the same thing, but "git blame" can be more fun / dramatic if you're looking into the cause of a problem.
Interestingly, "svn annotate" had 2 aliases: "svn blame" and "svn praise". But git didn't add a "praise" alias, just "blame". I actually almost submitted a PR to add "git praise" one time.
Anecdotal: I once helped out a team who was writing a Maven plugin for doing static tests on some js code during build. There was already a test suite with a bunch of test code. As my stuff was fairly complicated and I have a habit of writing unit tests for such I added a bunch. Fast forward a year and a half later: I was greeted with a mail that there was a bug in it. I had to fight the better part of a day to nail it down: First not being familiar any longer with the code and secondly because a bunch of stuff has been added meanwhile. I fixed and thought it was a good idea to add a test as it was a nasty corner case. I headed for the natural place where the test would go and found -- exactly the test I was going to write, nicely commented out. A quick check with Git revealed that I added this test initially, which then was commented out when the new feature causing the bug was added. Firing up git blame was next... This is why I am fond of having tests: you are stomped onto it if you break something at least if your test suite is worth its salt.