Extension not showing correct commit

[mcat115]

I have found multiple examples where the Git Blame VS Code extension does not link to the correct commit on GitHub. Here is an example where I wrote this brand new line 5 months ago, but the extension is linking to an earlier incorrect commit. This line did not even exist yet in the commit it is linking to.

[IsawU]

I have a similar experience.

A piece of boilerplate code was copied to a new file. And now the blame in the new file shows the same exact blame as the original file that the lines were copied from. A newly committed file suddenly showing a 5 years old blame from a person who did not even touch the commit where the file was created. Very confusing. Running git blame directly shows the correct blame info.

This would be in line with the above described (a 5 months old commit showing a blame 1 year ago (possibly a different person)). The "Online" link for GitLab links to the "5 years ago" commit. The file where this blame shows up did not exist at that point.

Some additional info:

The original file is hundreds of lines long and only around 4 lines were copied from the original file. The destination file also contains more than just the copied lines. This to me feels like some unfortunate caching, but I was unable to prove anything along this line of reasoning.

What I tried:

• Close any open editor tabs with the old original file and reload the window. (In a hope that the opened new file will be processed first.)
• Delete the old original file and reload the window. (Git obviously still knows about this old file, so I'm not sure if this would help.)
• Look for a cache directory in .vscode/extensions/waderyan.gitblame-10.5.1.
• Look for caching in source. (I found file-cache.ts, but I get the feeling it's only in-memory.)

[Sertion]

Hey Michael and George!

Do you get the same incorrect git blame information for those lines if you run git blame -C -- <filename> (replace <filename> with a path to the relevant file)?

It could be the C-flag making things look weird.

[IsawU]

Hi,

In my case it is definitely the -C copied lines detection. (I had no idea there was this option built-in.) If I run git blame -C -- <filename> I get the same blame as from the plugin (5 years ago, the file does not exist yet). If I run git blame -C200 -- <filename> (intentionally high <num> to avoid detecting this specific instance) I get the blame for the commit where this flie was comitted.

[Sertion]

Thanks for getting back so fast. If you want to refer to a file on the remote you need to use the ${file.path.source}-token (and perhaps ${file.line.source}).

Perhaps they should be changed to be the default behavior of ${file.path} and ${file.line}.

[mcat115]

When I run that command it show's the incorrect commit, like is shown in the plugin. @Sertion what exact settings should I change to make it show the correct commit like is on GitHub?

[IsawU]

A setting to modify the default behavior would be nice. (I explored more ideas, but after I stumbled upon the following, I discarded them.)

After further reading it seems that the incremental output (git blame -C --incremental) is perhaps what is meant to be consumed by a machine and contains all the relevant changes in a single output. The extension could this way display both the latest commit and any commits that the author copied from.

[Sertion]

@mcat115, Please change any instances of ${file.path} in your gitblame.commitUrl-configuration option to ${file.path.source}.

@IsawU, The extension currently uses the incremental (or porcelain) output. There is no good way to show more than one commit in the interface as is.

I'll close this as not a bug.

[mcat115]

@Sertion like this? It doesn't work

[Sertion]

@mcat115, If you use the default value for gitblame.commitUrl (the property in vscode, not a token for the property) you don't need to change anything.

If you had changed it so that instead of linking to the commit it instead linked to the file where the change came from then you would have needed to make the change I proposed.

[mcat115]

@Sertion I do use the default value, I've never changed it, yet I am still having this issue. When I run git blame -C -- <filename> I also see the incorrect commit. If you closed this as not an issue, what am I doing wrong?

[mcat115]

Sorry I'm a bit confused, I appreciate the help :)