Is there a command that can be run to get the TFS remote for a Git branch, if any?
See original GitHub issue- I have read the documentation about command line options and advanced use cases
- upgrade and test with the last version
- specify the version you are using
- include steps you followed to reproduce the problem
- if the problem occurs when using a git-tfs command, please provide the output of the command when using the
--debug
command line option (providing a gist could be a clever idea 😉)
So, I’ve been looking all around the documentation for a while to find what I’m looking for. There are some commands which seem to accomplish what I work, but it requires I have some information “up front”, which, in a scripted scenario, I just might not have.
I’m currently using v0.25.0 of Git-TFS.
I’m trying to determine what the Git-TFS TFS remote is for an arbitrary branch. Check out the scenario below. Assume that I have cloned the root of my TFS Project.
$ git tfs branch --init $/MyTFSProject/Feature/My-Cool-Feature
# I believe this puts me on a git branch Feature/My-Cool-Feature. If not, assume I checked it out now
$ git branch Feature/foo-bar Feature/My-Cool-Feature
$ git checkout Feature/foo-bar
$ git tfs bootstrap
commit abc123def456...
Author: Joe Blow <joe.blow@somedomain.com>
Date: Sun Jan 01 00:00:00 +00:00
my commit message
work-items: #12345
git-tfs-id: [http://url-to-tfs:8080/tfs/MyTFSProjectCollection]$/MyTFSProject/Feature/My-Cool-Feature;C6789
-> existing remote Feature/My-Cool-Feature (up to date)
$ git tfs branch
...
Feature/My-Cool-Feature -> http://url-to-tfs:8080/tfs/MyTFSProjectCollection $/MyTFSProject/Feature/My-Cool-Feature
refs/remotes/tfs/Feature/My-Cool-Feature - abc123def456... @ 6789
So, in the output of git tfs branch
above, it only shows the one branch as being “tied” to the TFS remote. It does not output the fact that the branch Feature/foo-bar
is also “bootstrapped” to the TFS remote tfs-remote.Feature/My-Cool-Feature.
Now, I could just issue an additional git tfs bootstrap
command. This should be a no-op since the branch is already bootstrapped–but I really shouldn’t depend on that being the case. For example, in a scripted scenario (which is what I’m trying to accomplish), if the git branch is not bootstrapped, I don’t necessarily want to bootstrap it (if it’s even possible)–that may not be what the user wants. So I can’t really use this command to obtain the output I desire because of unintended side effects (i.e. that’s really not what git tfs bootstrap
was made for).
Trolling around the .git
dir, I was looking for any kind of files that would contain this tracking information. How does Git-TFS know, in this instance, that Feature/foo-bar
is “tracking” refs/remotes/tfs/Feature/My-Cool-Feature
? (Is it parsing the reflog? If so, it appears it may be stopping at the first successful match.)
If this feature does not exist, please consider this a feature request to add a command to Git-TFS:
As a git-tfs user, I want to be able to issue a command to determine which TFS remote a git branch is tracking So that I can perform scripted operations against the git branch and the TFS remote
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (10 by maintainers)
My colleagues and I have created a script that allow us to set and then get this information, modeled after the standard
git-remote
command. We also have an automated script that allows us to maintain a shared git repository with TFS that my team uses in our organization. These scripts assume you’ve cloned extra metadata from your TFS VCS and that you’re using an authors file. Hopefully someone finds these useful.Here’s
git-tfs-remote.sh
:And here’s
git-tfs-sync.sh
:And here’s
git-tfs-merge.sh
(NOTE: this needs to be refactored to usegit-tfs-sync.sh
to remove a lot of duplicate code. We wrotegit-tfs-merge.sh
first before realizing we needed a way to associate git branches with TFS remotes.):@pmiossec Thanks for the explanations. OK, that makes sense you’re not using the ref-log. And I get what you’re doing. I guess I still don’t 100% understand why you can’t say a Git branch “tracks” a TFS remote.
Anyway, let me tell you what we’re doing.
We have a TFS Team Project that is fairly large (it took 26 hours to clone, anyway). I am on a 3-person team (and we’re one team out of 6) that are using this Git repository. The rest of the teams use TFS directly (our team really just likes the simplicity of Git, so we’re the “odd man out”).
OK, so what I did was clone the TFS repository. Then I pushed my repo’s branches up to an on-prem Atlassian Stash server so that the other two team members could clone from that. (We have this all figured out, and it’s working great. When I get around to it, I’m going to blog on it–perhaps even submit some documentation here on the process and how we work.) However, yesterday we ran into a bit of a problem–partly because we didn’t have a full understanding of what was going on; we just hadn’t thought everything through. Prior to yesterday, I was responsible for updating my local repository from TFS, and then updating the Atlassian Stash server that everyone else would then pull from. But, as you can imagine, I’m a bottleneck now.
My team is very smart, so there’s no need for me to be a bottle neck. We wrote a script that automated the process to merge a git topic branch back into a parent git feature branch (which is also a Git-TFS branch; i.e. the parent branch is “bootstrapped” to a Git-TFS remote). The script worked beautifully.
Now here’s where I went wrong. I let my copy of the parent branch become behind. (I did this on purpose–I wanted to check that everything was working as I expected). Knowing my local git feature branch was behind Stash and TFS, I pulled from TFS first. I then checked my hashes with the ones up on Stash and they were different! In hindsight, I should’ve expected this. (If any team member knows about a TFS branch in their Git repository that no one else knows about, especially the Stash server, there’s a potential for people’s hashes to not “line up”–and this is expected if you know what’s going on under the covers.)
What we learned was that, when working with multiple team members who are all updating TFS and Stash, the order in which you fetch/pull from Stash and TFS is important. Always pull from the centralized Stash server first, then pull from TFS; and after pulling from TFS, immediately push back to Stash. Then everyone remains in synch. (Yes, there is still a slight chance for this to go wrong–in this working scenario, you can’t 100% get rid of potential “race conditions”; but since there’s only 3 of us working on a shared TFS/Git branch, the likelihood of this race condition occurring is quite small).
So now I want to write a script that our team would run when “synchronizing” the Git-TFS feature branch so that everyone stays in synch. Here’s the basic outline of what the script would do:
git-tfs-pull
would get its changesets/commits from.origin
(i.e. make sure the local copy of the Git-TFS branch is up-to-date with the Atlassian Stash copy)git-tfs-pull -x -r
(Synchronize from TFS)As part of our process, no one ever commits directly to a branch that is “bootstrapped” to TFS. All work is always done on a topic branch branched off of a “bootstrapped” TFS branch. The only thing that ever commits to a “bootstrapped” TFS branch is
git-tfs-rcheckin
andgit-tfs-pull
.The only time we would need to use the above script is when forward-integrating changes from TFS/Main into TFS/Our-Feature-Branch and needing to “synchronize” our central git server (Atlassian Stash) with these changes.
Why do we use the centralized Git Server? So we can use a git-flow style of working, and then use the Pull Request feature for code reviews. Once the PR is approved, we use our custom “merge” script to
rcheckin
the changes to the Git-TFS branch and automatically close the PR on Stash. It’s really a sweet setup.