[android-kernel] Pro's / Con's on merge robots for tracking linux-4.9.y in android-4.9

[mark gross]

I recently noticed that the common.git/android-4.9 branch has started a new
(as of the v4.9.13 merge) way of doing merges from linux stable.

I must say that it hurts my eyes to look at that history as compared with
nice clean merges of tagged dot releases from linux stable. (e.g. v4.9.13
looks much nicer to me than what has happened after the v4.9.13 merge.)

What is the benefit of making the tree hard to comprehend?

Sure, merge conflicts are better isolated to specific changes this way but,
damn its ugly.

Maybe I just need to get used to it. :(

-- mark
create interesting things.

[John Stultz]

Post by mark gross
I recently noticed that the common.git/android-4.9 branch has started a new
(as of the v4.9.13 merge) way of doing merges from linux stable.
I must say that it hurts my eyes to look at that history as compared with
nice clean merges of tagged dot releases from linux stable. (e.g. v4.9.13
looks much nicer to me than what has happened after the v4.9.13 merge.)

Yea, I hadn't notice that myself. It is interesting to look at in tig.

Post by mark gross
What is the benefit of making the tree hard to comprehend?
Sure, merge conflicts are better isolated to specific changes this way but,
damn its ugly.

My guess, as the merges are seemingly done by a bot, is that by doing
a merge on each change, they can more easily validate each -stable
patch being added. I wonder if it might also make bisection easier,
as you likely won't end up on a branch missing the common.git bits.

But it does cause a lot of merge noise. I wonder if such iterative
auto-merge testing could be done in a separate private branch and once
done a more standard cumulative merge be done on the main branch. But
there may be other constraints I'm not aware of.

thanks
-john