3 ms·
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
by Izkata 3y ago
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.
- forrestthewoods 3y agoOne of these is waaaaaay more common of an operation than the other.
- vinnymac 3y agoThe fact that it was brought up early in the article, tells us which one is a more common operation as well.
- Izkata 3y agoMoving 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.
- mnsc 3y agoDoes this really work consistently? Like merging in a small java method into the middle of an existing class with a couple of methods.
- cerved 3y agoPretty sure the answer is no
- Izkata 3y agoThat'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.
- cerved 3y agooh cool, I didn't know that, thanks