On Wed, 07 Feb 2018 00:25:34 +0100, Linus Torvalds wrote: > > On Tue, Feb 6, 2018 at 3:44 AM, Mark Brown <broonie@xxxxxxxxxx> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
