Thoughts about "Create a new change for every commit not in the target branch"

[Richard Christie]

Hi

We have a group of developers who like to do branch-based reviews rather than per-commit reviews. I am wondering whether anyone can think of (or I have missed) a solution to a problem they are having in trying to make gerrit a little more like a "pull-request" system.

Situation:

• Developers tend to work on their own (non-reviewed) individual scratch branches.
• Eventually they create a merge commit to a reviewed feature branch 
• Gerrit is set to "Create a new change for every commit not in the target branch", so they get a whole run of commits they can then review. They rely on this behaviour.
• Assuming everything reviews it gets merged, but
• At some point they may then merge this reviewed feature branch to (say) master, and that then opens up a whole new set of 'already reviewed' reviews as a result.
• They don't want that

So questions are around:

Is it possible to override the project level "Create a new change for every commit not in the target branch" setting during a given push - i.e. as  a %magic to gerrit?

Alternatively is there a way anyone can think of getting around this problem? i.e. creating a raw change with the REST 'POST /changes/{change-id}/merge' with the existing branch head as the source by-pass and do what was wanted?

Or maybe via a patchset-creasted hook event?

[Saša Živkov]

On Wed, Jan 31, 2018 at 6:44 PM, Richard Christie <r.d.f.c...@gmail.com> wrote:

Hi

We have a group of developers who like to do branch-based reviews rather than per-commit reviews. I am wondering whether anyone can think of (or I have missed) a solution to a problem they are having in trying to make gerrit a little more like a "pull-request" system.

Situation:

• Developers tend to work on their own (non-reviewed) individual scratch branches.
• Eventually they create a merge commit to a reviewed feature branch 
• Gerrit is set to "Create a new change for every commit not in the target branch", so they get a whole run of commits they can then review. They rely on this behaviour.
• Assuming everything reviews it gets merged, but
• At some point they may then merge this reviewed feature branch to (say) master, and that then opens up a whole new set of 'already reviewed' reviews as a result.
• They don't want that

So questions are around:

Is it possible to override the project level "Create a new change for every commit not in the target branch" setting during a given push - i.e. as  a %magic to gerrit?

The "Create a new change for every commit not in the target branch" internally does nothing else but

setting the %base option [1] smartly, to achieve the desired behaviour.

Try using the %base option to achieve what you need :-)

[1] https://gerrit-review.googlesource.com/Documentation/user-upload.html#base 

Alternatively is there a way anyone can think of getting around this problem? i.e. creating a raw change with the REST 'POST /changes/{change-id}/merge' with the existing branch head as the source by-pass and do what was wanted?

Or maybe via a patchset-creasted hook event?

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

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Christie]

On Wednesday, 31 January 2018 21:54:31 UTC, zivkov wrote:

On Wed, Jan 31, 2018 at 6:44 PM, Richard Christie <r.d.f.c...@gmail.com> wrote:

Hi

We have a group of developers who like to do branch-based reviews rather than per-commit reviews. I am wondering whether anyone can think of (or I have missed) a solution to a problem they are having in trying to make gerrit a little more like a "pull-request" system.

Situation:

• Developers tend to work on their own (non-reviewed) individual scratch branches.
• Eventually they create a merge commit to a reviewed feature branch 
• Gerrit is set to "Create a new change for every commit not in the target branch", so they get a whole run of commits they can then review. They rely on this behaviour.
• Assuming everything reviews it gets merged, but
• At some point they may then merge this reviewed feature branch to (say) master, and that then opens up a whole new set of 'already reviewed' reviews as a result.
• They don't want that

So questions are around:

Is it possible to override the project level "Create a new change for every commit not in the target branch" setting during a given push - i.e. as  a %magic to gerrit?

The "Create a new change for every commit not in the target branch" internally does nothing else but

setting the %base option [1] smartly, to achieve the desired behaviour.

Try using the %base option to achieve what you need :-)

[1] https://gerrit-review.googlesource.com/Documentation/user-upload.html#base 

Thanks for the info, that works as you describe.

Is there any way from the REST API to automate this. I had a play with the create change (POST /changes/), but that doesn't appear to have a way to associate an existing commit in the repo with the created change. The only way I saw was to use the merge option, which obviously doesn't do what the devs want.

Reason was looking at a way to potentially automate the 'doing-the-right-thing' by a callback from the patch-set-created event generated by the merge arriving (assuming that the auto-generation is turned off).