On Wednesday, October 10, 2012 9:04:03 PM UTC+2, kramer.newsreader wrote:
> Hi guys,
> Total git n00b here. Thanks in advance for the help. I am really having
> trouble. I am working in a new system. We are using git as a versioning
> system and gerrit as a review system/remote repository.
> Anyway, I was working on the branch 'master' and switched to another
> branch call it 12345, did some work there, made some checkins, pushed them
> to gerrit, no problem.
> Then I tried to switch back to master and the problems started. I
> switched back by doing git checkout master.
> When I switched back, git told me that my branch was behind remote (or
> possibly ahead, I'm not sure and can't reproduce the message).
> I did a git pull to get back into sync and a commit to separate the work
> I'm doing from the changes the pull did. I made my changes and did a
> commit. Then I tried to push to gerrit. Gerrit refused to accept my push
> saying that I don't have permission to push a merge.
> I didn't mean to do a merge at all, so I decided to look at my changes
> using git log (see a sanitized version of the git log output below).
> From the output, it seems that the pull actually did a merge (commit
> Did I make a mistake in doing the pull at that point?
> I didn't want to merge anything, I just wanted to sync my branch master to
> the remote master. I had no files in play. What should I have done?
Git pull means to first do a git fetch, and then merge (pull = fetch +
merge). A lot of people fall into this trap, hence there are a lot of
articles around like these:
There is a context where git pull's default behavior makes sense, but it is
not the case in teams where everyone are developing directly on the master
branch. If you work on master, and you just want to sync before you push a
little commit, you're better off doing git pull --rebase when you want to
sync (or any of the other ways suggested in the articles above).
So, let's clean up your "mess" here.
Your commit dc613fdf1273fc5d002beccc3bc2c93f4ddc3f61 is an accidental merge
commit, you want to get rid of that, I suppose.
What you want to do is to apply the patch contained in the
commit d97ceffd44a453b18bc25261c7572497d749b1c5 (your last commit) and
apply it directly after 7d7c37b1cff1acee33405ba5d67cc3d7fc8457cf, the last
commit on the remote master.
So, assuming the remote name of your repository is origin, you want to do
something like this:
git checkout master # make sure you're on the master branch
git reset --hard origin/master # completely reset your local master to be
in the same state as the remote master
git cherry-pick d97ceffd44a453b18bc25261c7572497d749b1c5 # cherry-pick in
your last commit
Now you should be ready to push again.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at