Question

I am working to get my group using git (were using svn). We have a ‘central’ system with a bare repository as our shared/backup system. There are 2 respositories at the moment, both for testing git – call them A and B. To start things off simply, we’re using this cycle (and only 2 people are testing so far):

- edit and commit
- git fetch origin
- git diff origin/master master # to see what merge will do
- git merge origin/master master  # merge
- git push   # share the merged commit

For repository A, if one person makes a change, then the other does the fetch/merge/push, the state of things ‘settles down’ to where both people show ‘Everything up-to-date’ for git push.

However in repository B we have a ‘ping pong’ effect that keeps producing new merge comments. gitk shows one commit as “merge branch ‘master’, remote branch origin/master” and the next says “merge branch ‘master’, remote-TRACKING branch origin/master”. [I put TRACKING in caps to show the difference.] The ‘git remote show origin’ show the same info for both users.

I’m sure the problem is obvious to one of you GIT pro’s – please enlighten us! Thanks.

Answer 1

Your problem is related to the fact that you’re incorrectly using the merge command:

git merge branch1 topic 

is going to produce an “octopus” merge which has more than two parents.

Instead for merge you should use:

git checkout master
git merge origin/master

Another possibility is that if two persons are working on repo B and they follow your scenario by the book – they will have this problem of merge commits appearing all the time.
In case if you’re developing in master branch and you know that somebody else might have updated it you should use (you are in master branch):

git commit ...
git fetch origin
git diff origin/master master
git rebase origin/master

That will streamline the history.

Now shorter variant of this will be (if you’re ok to review diffs later):

git commit 
git pull --rebase 

Hope that helps!