The central problem here is neglecting to identify the purpose of branches [1] and a haphazard attitude toward "merging from upstream" [2,3].
If you use topic branches for every feature and bug fix, then you can even test them in an integration branch (often called 'next') so that they can interact with other new features before graduating to 'master'. This makes 'master' more stable which is good for users and good for developers because they can be more confident that a bug in their topic branch was introduced in their branch. It is also easier to make releases.
Use of a 'next' integration branch also relieves some of the pressure from merging new features. Other developers' _work_ is not affected if 'next' is broken and the merge can be reverted without impacting the history that ultimately makes it into 'master'. Running 'git log --first-parent master' [4] will show only merges, one per feature, and each feature has already been tested in 'next', interacting with everything in 'master' as well as other new features. See gitworkflows(7) [5] for more on 'master'/'next'.
If we acknowledge that 'master' (and possibly 'next') are only for integration, then we don't have the problem of 'git pull' creating a funny merge commit because we're developing in a topic branch, but the same behavior occurs when we run 'git merge master' (or 'git pull origin master'). This is a merge from upstream and usually brings a lot of code that we don't understand into our branch. These "just keeping current" commits annoy Linus [2,3] because they do not advance the purpose of the topic branch ("to complete feature/bugfix X so that it can be merged to 'master'"). Linus' short and sweet rule of thumb [3] is
If you cannot explain what and why you merged, you
probably shouldn't be merging.
We can usually only explain a merge from upstream when we (a) merge a known stable point like a release or (b) merge because of a specific conflict/interaction, in which case that should go into the merge commit. If you use 'git merge --log', merges from topic branches contain a nice summary while merges from upstream usually have hundreds or thousands of commits that are unrelated to the purpose of your branch.
How do you know when to merge 'next' to master? It seems to me like you have the exact same problem as before, only now you're being interrupted because someone else broke next instead of master.
I could see it making more sense if you're on a well understood periodic release cycle, where breaking next isn't critical, and everyone knows to have it stabilized in time for the next release.
You never merge 'next' to 'master'. You merge topic branches when the topic is considered to be complete and stable (it "graduates"). The rerere [1,2,3] feature (a fantastic set-and-forget feature) ensures that you won't have to resolve the same conflict multiple times.
The amount of time required for a topic to stabilize in 'next' depends on the topic and what it affects, but you can easily summarize "branches in next, but not in master" to look for candidates.
Feature releases are tagged on 'master' and 'next' is usually rewound at a release (create a new 'next' branch starting at the release, merge all the branches that failed to graduate in this release cycle, and discard the old 'next'). This is easy to automate.
The central problem here is neglecting to acknowledge that other people and projects may have different needs and workflows. Linus doesn't hold the git truth, that's just how he decided to manage his project. Thankfully, one of git's redeeming features is that it's very flexible and can accommodate different ways of using it.
If you use topic branches for every feature and bug fix, then you can even test them in an integration branch (often called 'next') so that they can interact with other new features before graduating to 'master'. This makes 'master' more stable which is good for users and good for developers because they can be more confident that a bug in their topic branch was introduced in their branch. It is also easier to make releases.
Use of a 'next' integration branch also relieves some of the pressure from merging new features. Other developers' _work_ is not affected if 'next' is broken and the merge can be reverted without impacting the history that ultimately makes it into 'master'. Running 'git log --first-parent master' [4] will show only merges, one per feature, and each feature has already been tested in 'next', interacting with everything in 'master' as well as other new features. See gitworkflows(7) [5] for more on 'master'/'next'.
If we acknowledge that 'master' (and possibly 'next') are only for integration, then we don't have the problem of 'git pull' creating a funny merge commit because we're developing in a topic branch, but the same behavior occurs when we run 'git merge master' (or 'git pull origin master'). This is a merge from upstream and usually brings a lot of code that we don't understand into our branch. These "just keeping current" commits annoy Linus [2,3] because they do not advance the purpose of the topic branch ("to complete feature/bugfix X so that it can be merged to 'master'"). Linus' short and sweet rule of thumb [3] is
We can usually only explain a merge from upstream when we (a) merge a known stable point like a release or (b) merge because of a specific conflict/interaction, in which case that should go into the merge commit. If you use 'git merge --log', merges from topic branches contain a nice summary while merges from upstream usually have hundreds or thousands of commits that are unrelated to the purpose of your branch.[1] http://gitster.livejournal.com/42247.html (Junio Hamano: Fun with merges and purposes of branches)
[2] http://lwn.net/Articles/328436/ (Rebasing and merging: some git best practices)
[3] http://yarchive.net/comp/linux/git_merges_from_upstream.html (Linus Torvalds: Merges from upstream)
[4] http://git-blame.blogspot.com/2012/03/fun-with-first-parent.... (Junio Hamano: Fun with --first-parent)
[5] https://www.kernel.org/pub/software/scm/git/docs/gitworkflow...