We currently use "Rebase Always" merge strategy on gerrithub, which requires
each patch to be rebased on the latest version of its parent in order for that patch to be
merge-able. For this reason gerrithub reports merge conflicts on patches within a patch
series that was merged only partially. Getting rid of the merge conflict is extremely easy
- the rebase is usually flawless and there don't even have to be any real git
conflicts. I find this as an unnecessary gerrithub inconvenience. There are other merge
strategies on gerrithub , one of which is "Rebase if Necessary" which seems
to automatically do the above rebase. This could potentially create some unnecessary CI
traffic in our case, but the yet another "Cherry Pick" merge strategy looks like
a perfect fit - from my understanding it simply makes gerrithub no longer report merge
conflicts I've mentioned above - patches will be only marked as a merge conflict if
there's a real conflict in the code.
Is there any reason we stick to "Rebase Always"?