Dependent commits and the Cherry Pick integration model with Gerrit 2.4

[Greg Hurrell]

Hi all,

We just upgraded our Gerrit install from 2.2.1 and 2.4 and are enjoying the new features, but have discovered a couple of unfortunate kinks in the workflow when "Cherry Pick" is selected as an integration strategy. (We switched to the strategy a long time ago as the shape of the history graph was hard to read when using the "Merge If Necessary" strategy, and we were prepared to accept the cost of having to take care to submit chains of dependent changes in the correct order.)

Specifically, under 2.4, given a chain of 3 dependent commits:
 A -> B -> C

In the Gerrit UI this shows up as:

- on A: A is needed by B
- on B: B depends on A, B is needed by C
- on C: C depends on B

When A is submitted, the annotated version, A', appears in the UI and the dependency links go on A go away; eg. the UI shows all this as:

- on A: no dependency information shown
- on B: B depends on A (now marked red because A is an outdated version of A'), B is needed by C
- on C: C depends on B

The red marking is a little bit annoying because we're going to see it all the time in our cherry-picking integration model, but the fact that the dependency link disappears from A's page is actually quite inconvenient when you're trying to traverse a dependency chain and want to submit things in order. Unfortunately, Gerrit will only display dependency information for the latest patch set, so there's no way to reveal the dependency link for the pre-submission version of the patch set.

The workarounds we're considering are:

(0) Do nothing, and just change the way we interact with the tool; eg. we could open all the commits in the chain in separate browser tabs before starting to submit them, and then just jump from tab to tab; or we could start submitting from the command line using `gerrit review`; or we could search manually or with Gerrit's search mechanisms to find the next commit in a chain after submission.

(1) We could drop the cherry-pick integration strategy in favor of a "Merge If Necessary" one; this would mean no more annotations, and a messier history graph, but on the bright side would mean that Gerrit would actually enforce dependencies for us again.

(2) We could use the "Fast Forward Only" strategy. While this may sound onerous, it may not actually be as bad as it sounds, because the new Gerrit has a "Rebase" button right there in the UI. (Disclaimer: I haven't tried it yet). This would mean no more annotations and a clean history graph.

So, my questions are:

- Is there any configuration that could be set to turn off either the posting of the cherry-picked commit as a new patch set version, or the red highlighting of outdated dependencies?

- Does this sound like a bug (ie. the fact that the dependency link disappears; or the fact that in the cherry-pick model dependencies become immediately marked as "outdated") or a feature request (the ability to see dependency information for other versions than the latest patch set)?

- Are any other users of the cherry-pick strategy facing these issues, and if so what do they feel is the best way to resolve them?

- Any general opinions on whether the alternatives, especially the "Fast Forward Only" strategy + "Rebase" button, are viable?

Thanks for your input,

Greg

[Martin Fick]

> Unfortunately, Gerrit will only display dependency Information

>for the latest patch set, so there's no way to reveal the dependency
>link for the pre-submission version of the patch set

This should fix that:

https://gerrit-review.googlesource.com/#/c/35210/


Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum

[Greg Hurrell]

On May 26, 2012, at 4:30 PM, Martin Fick wrote:

>> Unfortunately, Gerrit will only display dependency Information
>> for the latest patch set, so there's no way to reveal the dependency
>> link for the pre-submission version of the patch set
>
> This should fix that:
>
> https://gerrit-review.googlesource.com/#/c/35210/

That's great. Thanks for that, Martin.

-Greg

[Saša Živkov]

On Sun, May 27, 2012 at 1:30 AM, Martin Fick <mf...@codeaurora.org> wrote:
>
>
>> Unfortunately, Gerrit will only display dependency Information
>>for the latest patch set, so there's no way to reveal the dependency
>>link for the pre-submission version of the patch set
>
> This should fix that:
>
>  https://gerrit-review.googlesource.com/#/c/35210/

When this change gets merged into master I will cherry-pick it into
stable-2.4 as preparation for 2.4.1.

Sasa Zivkov

>
>
> Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum
>

> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en

[Greg Hurrell]

On May 28, 2012, at 3:05 AM, Saša Živkov wrote:

> On Sun, May 27, 2012 at 1:30 AM, Martin Fick <mf...@codeaurora.org> wrote:
>>
>>
>>> Unfortunately, Gerrit will only display dependency Information
>>> for the latest patch set, so there's no way to reveal the dependency
>>> link for the pre-submission version of the patch set
>>
>> This should fix that:
>>
>> https://gerrit-review.googlesource.com/#/c/35210/
>
> When this change gets merged into master I will cherry-pick it into
> stable-2.4 as preparation for 2.4.1.

One thing to bear in mind: I noticed that it appears to depend on a database schema migration, although I didn't look at exactly where (ie. I just noticed that the patch works applied on top of HEAD of master, but not cherry-picked onto the 2.4 release).

-Greg

[Shane da Silva]

Hey Martin,

I realize this is an old discussion, but this behavior appears to have returned as of at least 2.10.4, possibly earlier.

It doesn't look like the ChangeDetailFactory modified by https://gerrit-review.googlesource.com/#/c/35210/ doesn't exist anymore, so it's likely this broke in a refactor.