Comment by ericbarrett
5 years ago
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.
>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.
> 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.
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).
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/
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?
3 replies →
> 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.
>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.