git-tf (2.0.2.20130214) does not sync folder rename correctly

Sep 10, 2013 at 9:12 AM
Hi Folks,
I find that when I rename a folder in git using "git mv f1 f2", commit and then execute a "git-tf checkin", a new folder f2 is created in TFS but the old folder with all of the sub-folders still survive. The files in the sub-folders are moved correctly.
In the TFS changeset details I see that while all the files in the subfolders are marked as "deleted, source rename" and a folder "f2" is marked with a change "add" there is no action to mark "f1" as "delete".
This appears to be a defect. Has this been the standard behavior in earlier versions of Git-TF as well?
Is this a known issue being worked on? I use git-tf on a Mac.

Thanks,
Shiva
Developer
Sep 10, 2013 at 11:05 PM
Hi Shiva,

The git-tf checkin command has an option:
--renamemode=<all|justFiles|none>
* The rename mode to use when pending changes. Specify either "all", "justFiles" or "none" 
* (default: justFiles)
You probably need to use it with the all value. In one of previous versions that was its default value. But by multiple user requests we changed it to justFiles recently.

Because of lack of information provided by Git regarding changes (e.g. in the git database rename always means delete+add) git-tf uses some heuristics to detect renames. Unfortunately, sometimes they could cause more issues than help. So, we decided to use more safe heuristics as default one.

Alex
Sep 11, 2013 at 8:54 AM
Hi Alex,

Thanks for the feedback. I've checked and this works as expected. I am now keen to understand the types of issues using "--renamemode=all" as a standard option to all commits could lead to.

We currently push unidirectionally from git to TFS so some scenarios may not apply (for now). I still need to make sure before I can publish this to our project teams with caveats.

Also curious to know the purpose served by the "--renamemode=none" option.

Best Regards,
Shiva
Developer
Sep 12, 2013 at 11:49 PM

Hi Shiva,

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..

1. remapemode=justfiles is the safest mode. At least you get the same heuristic you have in Git for individual files.

2. 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”.)

3. 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,

Alex

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…

Sep 16, 2013 at 1:02 PM
Edited Sep 16, 2013 at 1:34 PM
Hi Alex,

Thanks very much for the detailed explanation.

I have tested out a few scenarios with both the default and the --renamemode=all options and find issues with both:

default - file history cannot be tracked on file renames if the checkin rolls up commits which involve a rename and content change

--renamemode=all - behaves same as the default mode if folder moved to parent folder or sub-folder or in case of a folder split; by this I mean the original folder structure is left unchanged

I understand there are complexities involved with getting accurate change information from git. But in the current scenario, are there specific "git-tf checkin" guidelines which Microsoft offers the user community so that a "git-tf checkin" exactly reflects the Git workspace content in the checked-in TFS as well?

PS: We currently use TFS 2010 with plans to move to TFS 2012 next year. Could you provide some references I could review for Git repository hosting in TFS and requirements? (I understand this TFS feature is not yet released.) Our teams develop iOS and Android apps so are'nt interested in enhancements to MS Visual Studio to support Git.
Developer
Sep 25, 2013 at 4:15 PM
Hi Shiva,

You manage you Git repositories on TFS server using Web Access . You could create a Team Project with Git version control. By default one empty Git repository is created by that. Later on, you may create additional repositories in the same Team Project. You use these repositories as upstreams for local Git repositories in your team, i.e. you can clone, pull, and push from/to them. You may use any Git client you wish, e.g. command line or EGit.

Currently this feature is supported only on the hosted TF Service, i.e. http://tfs.visualstudio.com/. You may use this site to get understanding how TFS supports Git. In the learn section you could find how to create a Git repository with TF Service and use it with Eclipse or XCode.

Alex