Question

I’m using Git-tf to (obviously) skip TFS and be able to work offline and avoid the readonlys and all that tune …
Now .. I started cloning the tfs project in to lets say drive D: then I cloned again from drive c: (I think i was over paranoid there)

My current workflow is to commit the changes (in repo c:) to repo D: and then push the checkins to TFS

It works fine but it gets messy and I think I’m over complicating the workflow

What would be the best ?

could I configure the repo c: to point straight to TFS … and remove native git origin (repo d:)
Copy repo d: to c: and continue (I tried that and it works fine locally , but I didn’t commit any changes yet to TFS)
can I promote the repo c: to be ORIGIN (as in D:) and then continue to push changes to TFS from there (after git-tf config) ? …not sure about this promote thing …

Also: having in mind the project(as in C# vs2012) its a big project that is not that straight forward re-configure and build) not even mention to wait for the copy process 🙂 .
Any Other suggestions ?

Answer 1

You cannot configure repo C: to point straight to TFS. Repository D: contains the data about the git commit to TFS changeset mappings that were created when you fetched/cloned the repository. Without this data, git-tf cannot build a delta between the last changeset you fetched and your current commit in order to create a TFS changeset.

Copying D: to C: should be fine, as it will copy over the git-tf metadata that’s stored in the git repository.

I don’t know what you mean by “promote C: to D:“. If you cloned C: from D:, you could make changes and push them back to D: and then git-tf checkin them. It doesn’t really matter where the new git commits come from, if your HEAD points to a commit that is a child or grandchild of a commit that was created from the latest TFS changeset, git-tf can build a new changeset of the differences.