You get those "Merge branch 'master' of github.com:Username/Repository" commits, that introduce "unnecessary nonlinearities in the history" (to quote the reply).

I mean, it's not an huge problem (and that's why I still use git pull), but it does comport some kind of annoyance.

It seems that the SO answer doesn't understand that there is a `git pull --rebase` option. It attempts to rebase local commits on top of what was fetched, and by default shows merge issues if the conflicts could not be resolved automatically. It is my default for my workflow, but I will use different merge strategy when necessary (which is almost never).

git pull --rebase would take care of those nonlinearities.

In my experience, on projects with a few developers, --rebase is awesome.

Let's say I've got a copy on my server and a copy on my laptop.

I fix a typo in the README on the server, as that's the window I've got in front of me. I push the change, but don't pull it onto my laptop.

I don't pull the change to my laptop. I fix a different typo, and push it.

I pull down the new version on the server. I fix another typo. Now this commit has two parents: the one from the server earlier, and the new one from my laptop. Because it has two parents, it's a merge commit.

But why is that a problem? If you're merging changes from two different sources, of course the merge is going to have two parents. What else do you expect?