12

I'm using Visual Studio 2015 and the Microsoft Git client. I'm running into some problems with viewing history and annotations with the tooling because Visual Studio doesn't seem to handle file renames when viewing git history. Is there any good way around this?

BTW: I tried using the "Show Full History" toolbutton in the history viewer, but it still didn't actually show history with renames

Here's what I did to test:

  1. In Visual Studio, I right-clicked the file and selected "View History". (it only showed 4 commits)
  2. In the History Window, I clicked "Show Full History" -- still the same 4 commits.
  3. From the git command line, I ran git log --follow TheFile.cs (it produced 13 commits)
  4. In Atlassian Source Tree, I pulled of the log for the file, and I checked the "Follow Renamed Files" option. It pulled the same 13 commits as the command line.

What I really want is to have an option in Visual Studio that would match. Is that possible?

JMarsch
  • 21,484
  • 15
  • 77
  • 125
  • 1
    HItting this issue too. In one commit I renamed 1300+ files, many are seen as renames by visual studio and have corresponding file history shown, but a good chunk are not. The visual studio UI hides some of the uglier warts of git, namely diffing file revisions across renames, so it is a shame it doesn't work sometimes. I can still do the diff via the command line, but it requires specifying the revisions, the before and after path, and manually adjusting the similarity metric to 0 so that it works reliably! See 2nd answer at http://stackoverflow.com/questions/7759193/git-diff-renamed-file – aggieNick02 Sep 08 '16 at 17:02

1 Answers1

5

Visual Studio does follow history between two commits to determine if a file is renamed. Here, I've renamed a single file from its original name to renamed, and made a change to the contents at the same time:

File History

However, Git does not track changes between two commits - instead, it compares the snapshots of the commits to determine how files have changed. Thus, there is no rename information in the repository's history. Instead, this is calculated by comparing the file in the original commit to the file in the subsequent commit. If they are sufficiently similar, then Git will deem this a rename.

Since this is a heuristic, it's not guaranteed that this will be deemed to be a rename. However, Visual Studio and Git for Windows should agree on these things, generally speaking. I'd be curious why one reports this as a rename and the other does not. There are two possibilities:

  1. This file is very near the edge of similarity - say, Git has decided that the two revisions are 61% similar to each other and are thus a rename, while Visual Studio has decided that the two revisions are merely 59% similar, and thus are not a rename.
  2. There's some bug here where Visual Studio is not calculating the similarity correctly. If I had to guess, I would guess that there's a whitespace or line ending issue, because that's always a problem in Git.

If you're able to share the two revisions of this file, opening a connect bug or emailing them to me directly would help investigate further.

Edward Thomson
  • 74,857
  • 14
  • 158
  • 187
  • Hi Edward: I'm afraid that company policy will not allow me to share any of our source code. Using the --follow option in the git command line gives me the versions I expected, and that the oldest version that I can see from the cmd line differs quite a bit from the oldest version that VS shows .The older one, with the follow option only has 21 lines. The oldest one that Visual Studio shows has about 100 lines. I caught this problem while we were preparing to migrate from svn to git. Looking at the SVN history, it looks like the directory was renamed, and that is the oldest rev in VS. – JMarsch Sep 22 '15 at 13:36
  • For what it's worth, it does look like VS sees some of the renames -- when I was researching for migration, I learned how git tracks changes, and I was pleasantly surprised to see VS handling renames in my tests. This finding above is kind of an 11th-hour catch. I'm going to see if I can really track it down to directory renames. – JMarsch Sep 22 '15 at 13:38
  • My guess is VS not including "--follow" as an argument. I have done a rather large refactoring of your codebase. Outside VS I can see the history using "--follow". But VS will categorically stop at the "rename commit". – Jacob T. Nielsen Jun 29 '16 at 15:40
  • @JacobT.Nielsen There is no `--follow` argument. VS does not use the Git command line. There is likely a difference in the rename detection heuristic. If I had to guess, I would wager it had to do with line endings, because everything terrible has to do with that. – Edward Thomson Jun 29 '16 at 15:52
  • 2
    I'm a bit confused. From what I'm seeing, The git plugin that comes with Visual Studio 2015 is not showing the full history of the file. I've got a file I try to see the history on and it's only showing one commit, but at the command line "git log --follow THEFILE" shows all the previous commits. – Derek Greer Jan 26 '17 at 16:58
  • Hi guys! Does anyone knows if there is any progress in this case? We also have an actual problem after moving many files inside a repository. On some of the files Visual Studio 2019 recognises the movement but on many files even not! As long as we use the parameter '--follow' on git command line or the feature 'Follow renamed files' in SourceTree we see the complete history of the files BUT Visual Studio unfortunately not... – burgerS Oct 12 '20 at 10:36