[Development] Be careful with duplicate Change-Ids in multiple branches in gerrit

Oswald Buddenhagen oswald.buddenhagen at gmx.de
Tue May 7 22:13:28 CEST 2019

On Tue, May 07, 2019 at 01:52:48PM +0000, Liang Qi wrote:
> This is a very common issue when I do the integraton work in qt5.
> For example, currently we have 5.12->5.13->dev merge order, and the last round 5.13->5.13.0 today. One change(changeA) had been integrated in 5.13, and another change(changeB) with duplicate Change-Id was pushed to 5.13.0 branch with status:open. When I try to merge 5.13 to 5.13.0, the changeB will be picked up by gerrit and be part of the integration, which I found in COIN. Normally that integation will fail, but I am not 100% sure.
> I only know the phenomenon, but not the root cause.
> If you have a change was merged in lower branch, please try to avoid use duplicate Change-Id in upper branch, at least in the current merge order.
please don't give such bad advice.

firstly, the issue occurs only if neither change was integrated yet.
i've yet to see actual evidence of another case.
and yes, that's a bug in the gerrit CI customization. one can only hope
that The Upgrade will fix it.

secondly, if you're doing a cherry-pick which will be followed by a
merge, _then you're doing it wrong_. most commonly, that will be the
effect of client-side re-targeting where the original change was not

> If you have a change landed in 5.12, and it's ok to have duplicate Change-Id when you cherry-picked it to 5.9, because we don't do merge from 5.9 to 5.12.
> Best Regards,
> Liang
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

More information about the Development mailing list