|From:||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|To:||Mark Brown <broonie-AT-kernel.org>|
|Subject:||Re: [GIT PULL] regulator updates for v3.13-rc1|
|Date:||Tue, 21 Jan 2014 11:16:57 -0800|
|Cc:||Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>, Liam Girdwood <lgirdwood-AT-gmail.com>|
On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <email@example.com> 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. Christ. When you start doing octopus merges, you don't do it by half measures, do you? I just pulled the sound updates from Takashi, and as a result got your merge commit 2cde51fbd0f3. That one has 66 parents. That kind of merge either needs to be split up, or gitk needs to be made better about visualizing it, because it ends up being *so* wide that the history is hard to read. I think you'll find that having that many parents also breaks old versions of git. Anyway, I'd suggest you try to limit octopus merges to ~15 parents or less to make the visualization tools not go crazy. Maybe aim for just 10 or so in most cases. It's pulled, and it's fine, but there's clearly a balance between "octopus merges are fine" and "Christ, that's not an octopus, that's a Cthulhu merge". Linus
Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds