[alsa-devel] [GIT PULL] Extra ASoC updates for v4.16

[Takashi Iwai]

On Wed, 07 Feb 2018 00:25:34 +0100,
Linus Torvalds wrote:
> 
> On Tue, Feb 6, 2018 at 3:44 AM, Mark Brown <broonie at kernel.org> wrote:
> > This pull request is for things that arrived in the last week of the
> > v4.15 cycle, I'm sending it directly since Takashi still seems to be on
> > holiday (I'd thought he'd be back this week).

Sorry for that, I'm having a really bad net connection at our hotel,
so I cannot respond each mail and work on my git tree...

> > There's some random new
> > development in here and also a bunch of bugfixes.
> 
> No. I'm not taking this completely crazy stuff.
> 
> It has 54 commits total. Of those, 35 are merges. Many of those merges
> are complicated octopus merges that don't bring in _anything_ new,
> because the commits they merge all came in through some other source.
> 
> Really. Ask yourself - why would I take that kind of complete and
> utter mess, where two thirds of the commits don't actually do anything
> but mess up the history and make things hard to follow?

Mark has been always a torturer for git merge, so it's not new :)
I used to have multiple topic branches in the past, so I have
understanding of his management style.  A topic branch per vendor is
sometimes nicer to make the changes isolated from others.  Though, I
agree that the case like this is too much, too.  Maybe at most a few
(3-5) topic branches?

> > Unfortunately I can't figure out how to generate a sensible git pull
> > request for this since it ended up containing both v4.15-rc9 and my
> > prior pull requests.
> 
> git pull-request doesn't necessarily work if you have complex history,
> and this is more complex than most, by a long shot.
> 
> In fact, it was so complex that just "git merge" - which usually
> completes in under a second - spent a lot of CPU time on that merge
> from hell. It probably had a ton of different common merge points that
> all ended up being recursively merged together to get a base for the
> final merge.
> 
> [ Whee. I went back and looked. There's 88 merge-bases. EIGHTY-EIGHT!
> Christ. That must be some kind of record. Poor git. It did end up with
> a clean merge in the end, but no wonder it took tens of seconds to do
> so ]
> 
> It is expected that anybody who doesn't have a linear history knows
> how to do a test merge and report the result that way.
> 
> That said, history really generally isn't expected to be this messy
> _anyway_. This looks like some drug-induced frenzy of "let's just
> merge random branches for no good reason even if they have been merged
> earlier".
> 
> So pulled and then unpulled in horror.
> 
> Because some of those merges look very Lovecraftian, with the whole
> gigantic octopus merge theme. Cthulhu and tentacles galore.

So, would you suggest to straighten commits by rebase at this time?
The rebase was a thing to be avoided in general, and that's the reason
of the messy multiple merges.

In anyway, Mark, please send a renewed pull request to Linus directly
for this fix, as I'll still be less responsive until the next
weekend.


thanks,

Takashi