Hacker News Reader

Comment by Izkata | Hacker News Reader

The flipside is when two files are combined, git blame can track history across both sources. Can't do that when explicit moves are recorded, one of the source files would be recorded and the others treated as new lines.

View on HN

One of these is waaaaaay more common of an operation than the other.

The fact that it was brought up early in the article, tells us which one is a more common operation as well.

Moving single functions or groups of lines (like extracting something common into a function) I'd say is more common than even that, and this same functionality tracks those changes across files too.

Does this really work consistently? Like merging in a small java method into the middle of an existing class with a couple of methods.

Pretty sure the answer is no

That's what the -C flag is for, to make it more/less sensitive. So answer is "yes, if you use it", and this is what it looks like:

  $ git blame file3 -C1
  9afddd5e file3 (Izkata 2024-01-01 11:40:51 -0600 1) 
  9c8635a7 file2 (Izkata 2024-01-01 11:40:27 -0600 2) 4
  9c8635a7 file1 (Izkata 2024-01-01 11:40:27 -0600 3) e
  9afddd5e file3 (Izkata 2024-01-01 11:40:51 -0600 4)

Also fun fact, -C can be given up to 3 times:

1 - Look for the source in files modified in the same commit

2 - Look for the source in any file that existed as of that same commit

3 - Look for the source in any commit

Great for if you suspect the original committer didn't do the delete/add (move) in one commit.

oh cool, I didn't know that, thanks

Reply on news.ycombinator.com