4 ms·

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.

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.

ericbarrett 5y 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.
- SassyGrapefruit 5y ago
  >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.
  - triceratops 5y ago
    > 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.
    - SassyGrapefruit 5y ago
      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?
      - triceratops 5y ago
        Good idea. TIL. (I'm embarrassed I didn't think of it before)
      - richardxia 5y ago
        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.
        erik_seaberg 5y ago
        git blame --ignore-rev helps with filtering out meaningless changes in commits.
    - nemetroid 5y ago
      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).
    - jimpudar 5y ago
      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/ https://www.syntevo.com/deepgit/
  - NortySpock 5y ago
    > 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.
    - SassyGrapefruit 5y ago
      >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.
triceratops 5y ago
Code never gets moved or refactored by someone other than the original author?
- kapp_in_life 5y ago
  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.
  - triceratops 5y ago
    I'm embarrassed I didn't think of that before.
    - kapp_in_life 5y ago
      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.
- SassyGrapefruit 5y ago
  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.
- deleted 5y ago
  [deleted]
gher-shyu3i 5y ago
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.

ericbarrett 5y 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.

SassyGrapefruit 5y ago
>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.
- triceratops 5y ago
  > 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.
  - SassyGrapefruit 5y ago
    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?
    - triceratops 5y ago
      Good idea. TIL. (I'm embarrassed I didn't think of it before)
    - richardxia 5y ago
      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.
      - erik_seaberg 5y ago
        git blame --ignore-rev helps with filtering out meaningless changes in commits.
  - nemetroid 5y ago
    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).
  - jimpudar 5y ago
    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/ https://www.syntevo.com/deepgit/
- NortySpock 5y ago
  > 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.
  - SassyGrapefruit 5y ago
    >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.

triceratops 5y ago

Code never gets moved or refactored by someone other than the original author?

kapp_in_life 5y ago
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.
- triceratops 5y ago
  I'm embarrassed I didn't think of that before.
  - kapp_in_life 5y ago
    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.
SassyGrapefruit 5y ago
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.
deleted 5y ago
[deleted]

gher-shyu3i 5y ago

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.