linux-kernel - Re: [GIT PULL] regulator updates for v3.13-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jan 2014 20:31:38 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [GIT PULL] regulator updates for v3.13-rc1

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@...nel.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?

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)