4 ms·

Stop using git blame to look up who authored code, it's not a useful tool. Use git log -S <string> to search for changes to that line (then repeat with the prev

Stop using git blame to look up who authored code, it's not a useful tool. Use git log -S <string> to search for changes to that line (then repeat with the previous version of that line, until you find the original author), and/or git log -L to track changes to a code block. Don't waste your time with git blame.

nicoburns 5y ago
My editor (sublime text) has built in git blame support. It's literally right-click -> blame file, and it will put the author of every line in the margin.
- Icathian 5y ago
  Gitlens extension in vscode is quite good for this as well
- stevebmark 5y ago
  and?
ffjffsfr 5y ago
how is git log -S more efficient? You have to write whole line, what if line is long? What if you need to look at several lines within some range. git blame is much better than your git log -S
- DannyBee 5y ago
  git blame can't possibly work well in all cases, which is why the author is saying that. Git doesn't store what actually was changed. Git stores how to reconstruct the new file from the old file in a space efficient way. This is unrelated to storage of who changed what, only "what is the minimal way to reproduce the end state from the beginning state". As a result, tools like blame take the two versions and try to figure out what someone actually changed, trying to turn applesauce back into apples. Whether it gets it right or not has an element of luck to it (the diff algorithms are also often based on finding the minimal sequence of edits.). Whether it happens depends on the algorithm and it's heuristics, and often whether there is a single unique minimal sequences that could produce your end state from your beginning state (if not, it's not actually possible to say what you changed with 100% accuracy) git log -S instead is saying "give me all the times this line seems to have changed", and then you do the work of figuring out which were real and which are artifacts of the diff algorithm.
  - emodendroket 5y ago
    It doesn't have to be that detailed or bullet-proof to be good enough for like 90% of cases.
    - DannyBee 5y ago
      I actually don't have a strong opinion, i'm just responding to the comment about why they suggest what they suggest.
- stevebmark 5y ago
  you... copy and paste it?
cerved 5y ago
it depends on the code base but I get your sentiment
dasil003 5y ago
git blame and git log -S are both granular tools with their own blindspots. To actually get to the bottom of something you need a higher level tool which lets you iterate through historical changes across multiple files over time. The workflow is 1) git blame problematic area 2) open full commit + diff for that change so you can see context 3) open relevant file(s) as they existed in that commit 4) repeat steps 1,2 and 3 until you get to root cause. This workflow is not subject to any limitations around code structure, variable naming, file moving or anything else. fugitive.vim is a plugin which lets you very quickly recurse into history in this fashion using multiple vim windows.

nicoburns 5y ago

My editor (sublime text) has built in git blame support. It's literally right-click -> blame file, and it will put the author of every line in the margin.

Icathian 5y ago
Gitlens extension in vscode is quite good for this as well
stevebmark 5y ago
and?

ffjffsfr 5y ago

how is git log -S more efficient? You have to write whole line, what if line is long? What if you need to look at several lines within some range. git blame is much better than your git log -S

DannyBee 5y ago
git blame can't possibly work well in all cases, which is why the author is saying that. Git doesn't store what actually was changed. Git stores how to reconstruct the new file from the old file in a space efficient way. This is unrelated to storage of who changed what, only "what is the minimal way to reproduce the end state from the beginning state". As a result, tools like blame take the two versions and try to figure out what someone actually changed, trying to turn applesauce back into apples. Whether it gets it right or not has an element of luck to it (the diff algorithms are also often based on finding the minimal sequence of edits.). Whether it happens depends on the algorithm and it's heuristics, and often whether there is a single unique minimal sequences that could produce your end state from your beginning state (if not, it's not actually possible to say what you changed with 100% accuracy) git log -S instead is saying "give me all the times this line seems to have changed", and then you do the work of figuring out which were real and which are artifacts of the diff algorithm.
- emodendroket 5y ago
  It doesn't have to be that detailed or bullet-proof to be good enough for like 90% of cases.
  - DannyBee 5y ago
    I actually don't have a strong opinion, i'm just responding to the comment about why they suggest what they suggest.
stevebmark 5y ago
you... copy and paste it?

cerved 5y ago

it depends on the code base but I get your sentiment

dasil003 5y ago

git blame and git log -S are both granular tools with their own blindspots. To actually get to the bottom of something you need a higher level tool which lets you iterate through historical changes across multiple files over time. The workflow is 1) git blame problematic area 2) open full commit + diff for that change so you can see context 3) open relevant file(s) as they existed in that commit 4) repeat steps 1,2 and 3 until you get to root cause. This workflow is not subject to any limitations around code structure, variable naming, file moving or anything else. fugitive.vim is a plugin which lets you very quickly recurse into history in this fashion using multiple vim windows.