All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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: Tue, 21 Jan 2014 20:31:38 +0000	[thread overview]
Message-ID: <20140121203137.GY17314@sirena.org.uk> (raw)
In-Reply-To: <CA+55aFxX3odNLBt1L6iAPGybekioqaW3SREmXywd_jnz_tDBeQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

On Tue, Jan 21, 2014 at 11:16:57AM -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?

:)  It seems Takashi was right then.

> 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.

Ah, I'd not noticed that one - I tend to find gitk output pretty hard to
work with at the best of times once you hit lots of merges in a short
time unless I limit it to particular subsets of code and once there's
filtering it seems to cope well with both approaches (modulo the detail
on the final merge commit).  Long lived branches that go from -rc1 to
the next merge window aren't at all friendly to visualisation tools.

I can easily limit it, anyway.  Or another option would be to have a
branch which collects the merges incrementally rather than respining
them all the time (but has no development itself) - I *think* that may
be a bit more friendly to visualisation tools if done right but I seem
to recall that such integration only branches were frowned upon?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-01-21 20:31 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 [this message]
2014-01-23  8:27       ` Takashi Iwai
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=20140121203137.GY17314@sirena.org.uk \
    --to=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.