All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Brown <broonie@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [GIT PULL] regulator updates for v3.13-rc1
Date: Thu, 23 Jan 2014 09:27:33 +0100	[thread overview]
Message-ID: <s5hzjmnt85m.wl%tiwai@suse.de> (raw)
In-Reply-To: <CA+55aFxX3odNLBt1L6iAPGybekioqaW3SREmXywd_jnz_tDBeQ@mail.gmail.com>

At Tue, 21 Jan 2014 11:16:57 -0800,
Linus Torvalds wrote:
> 
> 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.
> 
> 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.

Yep, sorry, it's my fault that I overlooked Medusa there.
I usually check with gitk, but at this time, I checked the results
only via --no-merges option for concentrating on the real changes.
Now I looked at it, and I was turned into sto..n...e......


Takashi

> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

  parent reply	other threads:[~2014-01-23  8:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25 17:40 [GIT PULL] regulator updates for v3.13-rc1 Mark Brown
2013-11-25 21:10 ` Linus Torvalds
2013-11-26  0:39   ` Mark Brown
2013-11-26  2:50     ` Linus Torvalds
2014-01-21 19:16     ` Linus Torvalds
2014-01-21 20:31       ` Mark Brown
2014-01-23  8:27       ` Takashi Iwai [this message]
2014-01-24  0:04       ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hzjmnt85m.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.