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