I feel like "Cherry Pick" wouldn't work (or work well) for large sets of
changes. I think it could also lead to errors if one of us core maintainers accidentally
merged the second (or third or fourth) patch in the series before the first one.
I do think "Rebase if Necessary" might be a bit better than "Rebase
Always" - in some cases where no patches have been merged to master since a patch was
pushed to Gerrit, that patch would not get rebased - it would just be a fast forward.
This article has some of its own opinions on the different merge strategies which I found
On 6/4/19, 11:01 PM, "SPDK on behalf of Stojaczyk, Dariusz"
<spdk-bounces(a)lists.01.org on behalf of dariusz.stojaczyk(a)intel.com> wrote:
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"?
SPDK mailing list