Heh, sorry, I forgot that always fetch/rebasing instead of fetch/merging is a personal "quirk" of mine. It's much better IMHO because then when I finally merge

Heh, sorry, I forgot that always fetch/rebasing instead of fetch/merging is a personal "quirk" of mine. It's much better IMHO because then when I finally merge my work from a long running feature branch, my colleagues see a single merge at that time and don't have their history polluted with all the little merges that happened when I happened to pull in others' changes ("phantom merges") but that they never actually got to see at the time. Especially for long running feature branches, you can end up with an extremely illegible spaghetti history by constantly merging with git pull. Like I said, rebase should really be the safe default and merge the scary weird one. The dogma that "rebases alter history (OH NO!) but merges are SO SAFE" is just misleading when you look at what the operations actually do. After all, rebase works exactly like merge worked in legacy SCMs like SVN, and merge does something completely novel. Therefore, merging should be reserved for when the feature branch is joined back into the mainline (thus preserving history that is already shared by the whole team), never for when newer mainline changes are joined back into the feature branch (no need to preserve "history" that nobody but me ever had-- it's not even history, it's more like metahistory, the history of when my history was updated -- actual linear history is still preserved), to avoid this nonlinear illegible spaghetti. This also prevents you from ending up with intermediate commits that don't build, thus making bisecting painful. This seems a little off topic, but I promise it's on topic-- I learned to use git this way the hard way when working on a team that indeed had the problem of lots of developers working on the same files with lots of feature branches.