This project is read-only.

File Rename TFS 2010

Aug 12, 2013 at 9:26 AM
When I rename a file against TFS 2010, it does a delete then add. In 2012 it is fine. Is this expected behaviour? Why can it not rename against 2010?
Aug 12, 2013 at 3:53 PM
Hi l_o_l,

We would like to investigate this issue. The behavior you've described is expected with TFS 2008, but in TFS 2010 some improvements were done. Could you please provide us with more information on the issue? Do you have Git-TF logs, could you provide us with them? (You could use my personal e-mail for that: ). Also it would be helpful if you provide more detailed description of the specific use case, e.g.
  • was the file just renamed, or some folders were renamed as well ?
  • were there any other changes pended for the renamed file (any edits, encoding changes, etc.)?
Aug 12, 2013 at 3:53 PM
As I investigate further, the vast majority of renames and moves are preserved. However I have at least one example where Git shows me a rename, and TFS took it as a delete add. Any ideas why this would be?
Aug 12, 2013 at 4:00 PM
Note that git shows you renames, but it doesn't actually store renames. It uses a similarity heuristic to determine whether a rename/add pair in history is sufficiently similar to be displayed as a rename or not.

You can tweak this using the -M flag to git diff.

I suspect that here you're right on the edge of similarity and that some difference between core git and the jgit libraries that we're using are causing these two implementations to see slightly different similarity numbers. Subsequently, core git will treat this rename/add pair as a rename, while git-tf treated it as a rename and and add.

If you can provide the original files, it may be useful to know how similar core git believes them to be versus jgit, but since fundamentally git repositories do not track renames, this logic will always be a bit fuzzy and even minor changes to the command line arguments to git diff can produce very different results.
Aug 12, 2013 at 4:50 PM
Unfortunately I can't give you the files due to them being proprietary etc. However I believe I have gotten to the bottom of it. The contents were completely unchanged except that we had inadvertently changed the line endings to unix like. The version of Git I am running seems to cope with this OK, but it would seem that Git-TF does not. This should not be an issue going forward as line endings should always be the Windows style for our group. As an aside, is it possible to modify the "similarity" settings for Git-TF if I hit a similar problem in the future?
Aug 12, 2013 at 10:35 PM
Hi l_o_l,

How is the line ending processing defined in your Git repository? Do you have .gitattributes file with the line "* text=auto" committed? (Please see dealing-with-line-endings.)

Aug 13, 2013 at 10:42 AM
Hi Alex,

We did not have the global .gitattributes configured, so thank you for the link. This should prevent such issues occurring again. Sorry to waste your time on this issue.