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

[Oswald Buddenhagen]

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
abandoned.

> 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