On Wed, 07 Feb 2018 00:25:34 +0100, Linus Torvalds wrote:
On Tue, Feb 6, 2018 at 3:44 AM, Mark Brown broonie@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