Messages in this thread | | | Date | Mon, 25 Nov 2013 18:50:33 -0800 | Subject | Re: [GIT PULL] regulator updates for v3.13-rc1 | From | Linus Torvalds <> |
| |
On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote: > > If you're OK with octopus merges for things like this I'll definitely > take another look at using them, the enormous stack of merge commits > always looks noisy to me in the logs and pull requests and for things > like driver updates there's unlikely to be much doubt about which branch > it was if there's a problem.
Yeah, I'm definitely ok with octopus merges, and I do them myself occasionally (especially with the -tip tree, which I get as many separate pull requests - see for example commit 669fc2f0c70a).
And various maintainers use them too - Ingo does them for x86, Russell King does them for ARM, Roland Dreier for infiniband, Paul McKenney for rcu stuff, etc etc. Len Brown used to do them for ACPI all the time.
But I do ask people to use them judiciously. Octopus merges are good for the "many small topic branches" kind of thing. But they should generally be avoided for big merges.
Obligatory git trick of the day:
git rev-list --parents HEAD | egrep '^.{128}' | cut -d' ' -f1 | git log --no-walk --stdin --oneline
shows you the octopus merges. A couple of the older ones are bogus and come from the bad old days when git didn't properly filter parent lists, so there are redundant parents making a commit _look_ like an octopus merge even though it's really just merging one branch. Maybe Takashi hit one of those bugs back when..
Linus
| |