I've started using Team Foundation Service 2012 (The cloud based offering) now that they have announced support for using Git as a source control solution.
My initial test was a single projected with a single Git repository named after the project.
Everything went well, I could clone the repo, commit push and pull from within Visual Studio 2012 and more importantly the work item association worked as well.
For the real project however, it made more sense to split the codebase across multiple Git repos in the TFS project.
There was no obstruction in doing this, the interface for Team Foundation Service supported it quite nicely....
BUT
Now I find that in Visual Studio 2012 there are a few issues and I wonder if I've either done something wrong, or if its just something that is not fully supported (yet?)
- After testing, I've found that if the Git repo does not have the same name as the project then you lose the ability to clone the repo easily. The default URL that comes up always assumes the Git repo is named after the projected.
- Likewise, when the repo does not have the same name, you completely lose the ability to associate work items with commits. It also displays "(Local)" after the Git repo name, as if it has no idea that its actually associated with the TFS Project at all.
Anyone else find this and perhaps a solution (while still allowing multiple Git repos under the same TFS Project) ?
UPDATE: Found a few links such as these two
So at least one other person has bumped into it.
The multiple repo's work fine if you use Git to push remotely to the correct repo URL, it only breaks down if you use the Visual Studio 2012 integration in terms of work item association and cloning the repo.
