subtree command - managing multiple TFS projects in a solution #344

gburgett opened this Issue Apr 7, 2013 · 5 comments


None yet
3 participants

gburgett commented Apr 7, 2013

My office uses a TFS repository with an odd source layout, which makes it impractical to pull down the entire root of the TFS server. We have multiple solutions which are composed of multiple TFS projects each, which facilitates reuse of some projects (such as our utilities project) between solutions.

I would like to see git-tfs have a command similar to git subtree, seen here:

using git-tfs subtree, I could add each of the TFS projects as a subtree of a "master" git repository, which would function as a solution. The main requirement would be having a "git-tfs checkin" pend all changes across all subtrees and check in as one changeset. If possible, it would be nice to see "git-tfs pull" pull down all changes from all TFS subtrees as well.

I have forked git-tfs and am working on this as I have spare time, but before I went too far I thought i'd see if anyone is already working on this or has any suggestions for functionality.


davidalpert commented Apr 7, 2013

Can you add a graphical representation of the layout that you use? I'm
having trouble picturing it from your description.


gburgett commented Apr 7, 2013

Sure. Below is a simplified version of our source layout. We have only 2 products but we have multiple "projects" housing shared code, one of which is our "InternalTools" project containing assorted utilities.

| Production
| | Product1
| | | MAIN
| | | Branch1

| | Product2
| | | MAIN
| | | Branch2

| | InternalTools
| | | MAIN
| | | Branch1
| | | Branch2

InternalTools is shared by both Product1 and Product2. We map separate workspaces for Product1 and Product2, with InternalTools mapped in each. If we have a branch of Product1, we have to make a corresponding branch of InternalTools. Similarly with Product2.

I currently use Git-TFS by having a "master" git repository that contains a submodule for product1, and a submodule for each of its dependent TFS projects. In the root I can use submodule foreach for pulling, i.e. "git submodule foreach 'git tfs pull'". This makes it easy to get latest changes. Unfortunately this prevents me from checking in some changes as one TFS changeset. For Product1 this is OK, since 90% of the tasks involve only the main TFS project, "Product1". For Product2 it is more like 50/50, so my current solution is unworkable.


gburgett commented Apr 7, 2013

I've made some progress on this already, I added 'git-tfs subtree add' which will create a new remote for the provided TFS project, name it subtree/[prefix], fetch it and then execute git subtree add --prefix=[prefix] subtree/[prefix]. The end result is that I can commit each project individually using the following workflow:

  • git-tfs subtree add -p=InternalTools [tfs_url] $/Production/InternalTools/MAIN
  • hack away...
  • git commit -m 'fixes task blah'
  • git subtree split -p InternalTools
  • git checkout InternalTools
  • git-tfs checkin --remote=subtree/InternalTools

I'm working on this at my fork here:

My plan is to have the subtree command get (or create) a TFS remote with the same server URL, which would be used as the "master" remote. Once I have the "master" remote, the command will map the subtree's workspace within that master remote, so that PendChangesToWorkspace on the "master" remote will pend all the subtree's changes as well. If all the subtrees do this for the same "master" remote, then checking in or shelving on the master remote will do what we need. It will also work for pulling.
The last thing to do after that is to ensure we do a git subtree split for each configured TFS subtree after a git-tfs merge or checkin is finished, that way we ensure the subtree branch histories are up to date.


spraints commented Apr 8, 2013

Nice! Another approach to this would be #229. In that issue, we talked about adding the ability to create a git-tfs repository from a workspace or a workspace mapping file.


gburgett commented Apr 12, 2013

I've opened a pull request, #350

gburgett closed this Apr 12, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment