The easiest way would be to find the head commit of the branch as it was immediately before the rebase started in the reflog...
git reflog
and to reset the current branch to it (with the usual caveats about being absolutely sure before reseting with the --hard option).
Suppose the old commit was HEAD@{2} in the ref log:
git reset --hard HEAD@{2}
In Windows, you may need to quote the reference:
git reset --hard "HEAD@{2}"
You can check the history of the candidate old head by just doing a git log HEAD@{2} (Windows: git log "HEAD@{2}").
If you've not disabled per branch reflogs you should be able to simply do git reflog branchname@{1} as a rebase detaches the branch head before reattaching to the final head. I would double check this, though as I haven't verified this recently.
Per default, all reflogs are activated for non-bare repositories:
[core]
logAllRefUpdates = true
In the simplest terms, git pull does a git fetch followed by a git merge.
You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/<remote>/. This operation never changes any of your own local branches under refs/heads, and is safe to do without changing your working copy. I have even heard of people running git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).
A git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.
From the Git documentation for git pull:
In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.
Best Answer
Install git-tf from Codeplex source, MS Downloads, or better yet:
choco install git-tfThen run the following commands:
First you need to configure your GIT repository
Check in the files, optionally persisting author/USERMAP:
This process is very slow, but it works, so ensure you have plenty of time to spend migrating. The only downside is that commit time will be the current checkin time, not the original changeset time.