Sorry for the delay with the answer. We’re pretty much busy with the oncoming release. On the other hand, I would like to answer your question as full as I can. I’ve sent requests for additional information to
former developers of the product (unfortunately, now they have other assignments). I’ll let you know as soon as I get any valuable information.
Meantime, I should say that I took some steps myself. The search for “renamemode” on the Git-TF (CodePlex) forum returns some results with rather serious problems. As I remember, investigating them we came across
some technical issues that prevent us to resolve the issue completely. Effects highly depend on specific user scenarios. Again, that’s for that TFS and Git paradigm are too different. Something that is impossible in TFS could be easy in Git, and vice versa
things that native and light in TFS are impossible in Git.
Just an example, as I said before, internally, Git does not have a notion on “rename”. Some tools compare files (each to each, i.e. NxN complexity on the file count) to detect “similar” contents. (Having said
that, I do understand that in most cases only files’ check-sums are compared.) Say, if files are 70% identical by content, but have different names, the tool treat them as “renamed and edited”. This is the information we get from Git. Fine, if Git users accept
that, we follow.
Now, imagine that a folder has changed its name and content (a list of children), was it renamed and edited? What if a folder with the old name still exists? Was the old folder split into two (most common situation).
Well, which one is the old folder with the rest of content (plus something new) and which one is the part split and renamed?
All the above is what I can see just at a glance… I’m sure, that more experienced people could provide you with additional examples. We spent a lot of time looking for common and safe solution. We’re working on
improvement of heuristics we’re using, and oncoming release, I hope, will proceed much better. On the other hand, heuristic is just a heuristic. So..
remapemode=justfiles is the safest mode. At least you get the same heuristic you have in Git for individual files.
remapemode=all is the safe enough if you rename folders and change their content in separate commits (Still if splitting involves significant and comparable sets of children, you cannot be sure,
which of parts will be “rename” and which one “add”.)
renamemode=all is the safest but most stupid
J approach matching the integral Git architecture – no “renames” only “deletes” and “adds”.
Feel free to let me know, if you need any additional information. I’ll keep you posted if I get any additional examples from my collogues. I do understand that being responsible for a team project you might more
details. No problem.
Thanks for the interest to our product,
P.S. I’ve just noticed… you mentioned: “We currently push unidirectionally from git to TFS…”. All we discussed
so far were issues of mapping from the Git architecture to the TFS one. So, I’m sorry to say, you probably cannot escape from them.
On the other hand, as your team is mostly using Git Version Control, have you considered to use new TFS feature, i.e. Git repositories hosting? If your company has a modern enough TFS server (that was not an AD,
just a guess J) or use a hosted account, you might create Team Projects with a Git Version Control there…