News for hackers. Stuff that matters.
Re:It's probably time to stop recommending Clean Code (2020) by SassyGrapefruit on Tuesday May 25, 2021 @11:08AM (#27277809)
I think most of what martin says is rubbish, but this is not. I have never had `git blame` fail...ever. I know what user is responsible for every line of code. Doing this is contemporaneous. Its right up there with commenting out blocks of code so you don't lose them.
Re:It's probably time to stop recommending Clean Code (2020) by ericbarrett on Tuesday May 25, 2021 @11:11AM (#27277858)
I don't know what to say, this is a real problem I have encountered in actual production code multiple times. Any code that lives longer than your company's source control of choice, style of choice, or code structure of choice is vulnerable. Moreover, what's the harm? It's more information, not less.
Re:It's probably time to stop recommending Clean Code (2020) by SassyGrapefruit on Tuesday May 25, 2021 @11:24AM (#27278053)
>Moreover, what's the harm? It's more information, not less

If your code is outliving your source control system you got bigger problems than whatever is in your comments. I can confidently say that in 25 years in this industry this isn't something I've encountered. So probably sufficiently low enough probability to safely ignore.

>Moreover, what's the harm? It's more information, not less.

Too much information is every bit as bad as too little.

Re:It's probably time to stop recommending Clean Code (2020) by triceratops on Tuesday May 25, 2021 @11:26AM (#27278075)
> I can confidently say that in 25 years in this industry this isn't something I've encountered.

I've been in the industry less than half that time and it's happened to me. blame will tell you the last person/commit to touch that line of code. To find out when it was originally written, I may have to (in some cases) manually binary search the history of the file.

Re:It's probably time to stop recommending Clean Code (2020) by nemetroid on Tuesday May 25, 2021 @11:40AM (#27278276)
If you're a CLI user, you should check out tig, which is a terminal UI for git. In the blame view, you can select a line and press "," to go to the blame view for the parent of the commit blamed for that line.

This lets you quickly traverse through the history of a file. Another good tool for digging into the history is the -S flag to "git log", which finds commits that added or removed a certain string (there's -G that searches for a regex, too).

Re:It's probably time to stop recommending Clean Code (2020) by jimpudar on Tuesday May 25, 2021 @12:41PM (#27279081)
If you prefer a GUI tool, DeepGit[0] is a very nice tool that allows you to do some pretty amazing code archeology. I use this all the time for figuring out how legacy code evolved over time.

[0] https://www.syntevo.com/deepgit/

Re:It's probably time to stop recommending Clean Code (2020) by SassyGrapefruit on Tuesday May 25, 2021 @11:37AM (#27278238)
why? Just go to the commit hash in the blame and run blame again.

All in all it has a negligible impact on the readability of the code. It's mostly aesthetic for me. It's ugly and only solves far fetched problems.

Do you scratch your name and SSN into the side of your car? What if your title blows away in the wind on the same day that city hall burns down destroying all ownership records?

Re:It's probably time to stop recommending Clean Code (2020) by richardxia on Tuesday May 25, 2021 @11:49AM (#27278390)
Was going to post the exact same thing. I make use of this repeated git blame method all the time, and for everyone who is just learning this for the first time, you'll actually want to write `git blame <commit>~` to go back one commit from the commit hash in the blame, because otherwise you'll still get the same results on the line you're looking at.

Also, if you're using GitHub, their Blame view also a button that looks like a stack of rectangles between the commit information and the code. Clicking that will essentially do the same thing command-line git operation above.

Re:It's probably time to stop recommending Clean Code (2020) by erik_seaberg on Tuesday May 25, 2021 @06:53PM (#27283813)
git blame --ignore-rev helps with filtering out meaningless changes in commits.
Re:It's probably time to stop recommending Clean Code (2020) by triceratops on Tuesday May 25, 2021 @11:41AM (#27278281)
Good idea. TIL.

(I'm embarrassed I didn't think of it before)

Re:It's probably time to stop recommending Clean Code (2020) by NortySpock on Tuesday May 25, 2021 @12:30PM (#27278923)
> If your code is outliving your source control system you got bigger problems than whatever is in your comments.

You've never been at a company that finds it needs to upgrade from $old_version_control_sytem to $newer_version_control_system?

Because I've never seen that done as a big-bang rollout, it's always been "oh that code lives in the new system now, and we only kept 6 months of history"

Even just having an architect manually move folders around in the version control system has broken the history.

Re:It's probably time to stop recommending Clean Code (2020) by SassyGrapefruit on Tuesday May 25, 2021 @12:54PM (#27279252)
>You've never been at a company that finds it needs to upgrade from $old_version_control_sytem to $newer_version_control_system?

I've done this maybe a dozen times. Its always been big bang and I've never lost any history I didn't choose to lose. In fact I just did this last week for a 10 year old project that moved from SVN to GIT.

If you work somewhere where someone tells you this isn't possible consider finding a new job or alternatively become their new source control lord with your new found powers. Moving things between SCM systems is about the easiest thing you can do. Its all sequentially structured and verifiable. The tools just work everytime.

Re:It's probably time to stop recommending Clean Code (2020) by triceratops on Tuesday May 25, 2021 @11:24AM (#27278061)
Code never gets moved or refactored by someone other than the original author?
Re:It's probably time to stop recommending Clean Code (2020) by kapp_in_life on Tuesday May 25, 2021 @11:38AM (#27278246)
So then you checkout at the refactor commit and look through the blame to continue searching. If you have to repeat this more than a few times then the person has probably left the company or hasn't touched the code in years so its better to understand it yourself before modifying.
Re:It's probably time to stop recommending Clean Code (2020) by triceratops on Tuesday May 25, 2021 @11:41AM (#27278286)
I'm embarrassed I didn't think of that before.
Re:It's probably time to stop recommending Clean Code (2020) by kapp_in_life on Thursday May 27, 2021 @02:26PM (#27306363)
No worries, after typing it out I definitely feel like there should be an easier way to say "show me the stack of commits that touched this line(s) of code", and I'm sure some git wizard has a fancy one liner that could more easily do that.
Re:It's probably time to stop recommending Clean Code (2020) by SassyGrapefruit on Tuesday May 25, 2021 @11:43AM (#27278302)
If it gets moved then the blame will tell me who moved it, It will also tell me what the hash was before it was moved. That hash will have all the original information. Same for the refactor case.
Re:It's probably time to stop recommending Clean Code (2020) by gher-shyu3i on Tuesday May 25, 2021 @11:30AM (#27278136)
The parent's comment holds when reformatting, especially in languages with suspect formatting practices like golang, where visibility rules are dictated by the case of the first letter (wat?) or how it attempts to align groups of constants or struct fields depending on the length of the longest field name. Ends up in completely unnecessary changes that divert away from the main diff.