Reputation: 5199
I am using TortoiseGit v 1.8.9.0 as my client.
I have a git repository with currently has 2 branches. The HEAD branch and also the 1.0.0-Enhancements branch.
The 1.0.0-Enhancements branch is not up to date in my local repository. So when I look at the commit history of this branch on my local using TortoiseGit it does not show the commits on this branch that I can see on the remote in GitWeb.
Here are two screenshots which illustrate that my local copy of the 1.0.0-Enhancements branch is missing commits.
-->History on my local using TortoiseGit
-->History of remote on GitWeb
My ultimate goal is to merge the 1.0.0-Enhancements branch into the HEAD branch however before I do this I believe that the 1.0.0-Enhancements branch should be up to date on my local.
I have been trying for a couple of hours now to try and find a way to fetch 1.0.0-Enhancements commit from the remote to my local but can't find a way. This is what I tried ...
Make tortoise Git Switch to 1.0.0-Enhancements branch.
Use tortoiseGit to fetch from the remote branch.
But after doing this when I look at the history of my 1.0.0-Enhancements branch the missing commits are still missing. Can someone help me with how I might fix this?
--Update for answer byt @CupCake--
TortoiseGit also comes with a bash prompt. I tried both your suggestions using the command line but they did not work. Here are the results.
But I did seem to make some progress with trying a git pull from the TortoiseGit UI.
Which seemed to work except it came back with an error:
git.exe pull -v --progress "origin" 1.0.0-ENHANCEMENTS
From ssh://upredmine/cvs/repo/codeRepository/git/repo04/EPOS/EPOSWeb * branch 1.0.0-ENHANCEMENTS -> FETCH_HEAD Updating 67b6537..ee38b20 error: The following untracked working tree files would be overwritten by merge: .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.m2e.discovery.prefs .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.mylyn.context.core.prefs
.metadata/version.ini Please move or remove them before you can merge. Aborting
git did not exit cleanly (exit code 1) (1094 ms @ 16/07/2014 3:32:47 PM)
Can you give me some feedback on this. Do I need to force an update or synch?
Upvotes: 2
Views: 8955
Reputation:
It looks like the problem that you're having is that you're only fetching your enhancements branch into your local repo, but you're not actually merging the remote-tracking branch origin/1.0.0-Enhancements
into your local 1.0.0-Enhancements
branch.
Basically, you're branches are set up like this (let X represent your enhancements branch):
As you see in the diagram above, there are 3 branches involved:
origin/X
, which keeps track of where the remote version of X is.By using git fetch
, you update the local remote-tracking branch origin/1.0.0-Enhancements
in your local repo...but that's a separate branch from your local 1.0.0-Enhancements
branch.
So, what you want to do is either:
git pull
, orgit merge
the remote-tracking branch.Note that git pull
is really just a combination of git fetch
followed by git merge
of the branch that you just fetched.
Since you've already fetched, you just need to merge origin/1.0.0-Enhancements
into your local 1.0.0-Enhancements
branch. I don't know how you do this in TortoiseGit (I stopped using that years ago), but if you want to do it from the command line, you simply do
git checkout 1.0.0-Enhancements
git merge origin/1.0.0-Enhancements
In the future, in cases where you didn't fetch first, you can execute a pull into your local branch from the remote branch instead. Again, I don't know how to do this in TortoiseGit anymore, but if you wanted to do it from the command line, you simply do
git checkout 1.0.0-Enhancements
git pull origin 1.0.0-Enhancements
So the symbolic reference origin/HEAD
is not a branch. It's simply a special reference that points to the default branch in the (bare) remote repo...the same branch that gets checked out by default by any clones of that repo.
In a non-bare repo, HEAD
is still a symbolic reference, but instead of pointing to a default branch, it instead points to either the currently checked out branch, or the currently checked out commit, if you're not currently on the tip of a branch (e.g. "detached HEAD" state).
Upvotes: 3