One of the people that are working with me on some crazy stuff always forgets to pull the newest revision of the repository before changing the content and so he has very often trouble with different versions when he decides to push his work to the master repository. His actual workaround is to check out the complete repository in a new directory and merge his changes by hand into this revision… Here is a little instruction to maximize his productivity and minimize the network traffic.

Lets assume we have a repository, created like this:

And we have one user, that clones this new repository and inits:

So we have some content in our root repo. Another user (our bad guy) clones that repository too:

So let a bit of time elapse, while user one is changing the root repository so that the testfile may look like this:

And of course, the changer commits his changes:

Ok, nothing bad happened, but now our special friend decides to work:

What do you think will happen if he tries to push his changes to the master repo? Your right, nothing but a error:

Mmmh, so lets try to pull the root repo:

Our friend would now check out the whole repository and insert his changes by hand, but whats the better solution? Merging the file! Git has a function called mergetool , you can merge the conflicts with a program of your choice. Some examples are vimdiff , xxdiff , emerge or also for GUI lovers kdiff3 . In this post I’ll use vimdiff :

So change the conflicting file(s), you will also see the changes made in root’s and in your local revision. If you’re done just save it and commit your merge:

Great, now there is nothing that prevents you from pushing your changes to the root repository:

I think this way of solving such conflicts maybe much more efficient than cloning the whole repository again and again and again ;)