Gerrit - raising reviews 'on behalf of' someone else.

[Ace Chandler]

Hi Folks,

We're using gerrit for a project, and I wondered if you could advise if it's possible for gerrit to raise reviews 'on behalf' of other people. 

Here's the scenario. In addition to the main /refs/for/master, we've been asked to create 'lightweight' team scratch branches (refs/scratch/teamA) - these just allow a push without without a review, so they function more as if gerrit was not there. These are  designated as areas where teams can collaborate quickly without having to get someone to +1 the code, and to have a build.

At some point later, when they are happy with the code, they'd then like to repush the head node of the scratch branch to refs/for/master; to assimilate into the main codebase. we think that it's likely that someone (call them a 'retargetter') will push the head of the scratch branch to master when they are happy with the code.

 Gerrit does the right thing and notices that the chain of commits leading up to the tip of the scratch branch have been outside of reviews, and generates a chain of reviews. 

The problem is that if one assumes a 2 or 3 person team has been collaborating on these scratch branches, gerrit refuses to create the review set when it stumbles on the first commit that is not by the retargetter. Clearly people could squash and push a single uber-commit, but then we'd lose granularity which is not desirable.

Would be ideal if gerrit could raise a review on behalf of someone else, but I'm not sure it's possible to do this.

Cheers

-Ace

[David Pursehouse]

You can do this if your user belongs to a group that has the Forge
Author [1] and Forge Committer [2] permissions.

[1]
http://gerrit-documentation.googlecode.com/svn/Documentation/2.7/access-control.html#category_forge_author

[2]
http://gerrit-documentation.googlecode.com/svn/Documentation/2.7/access-control.html#category_forge_committer

[Ace Chandler]

hmm - ok. Thanks for the response. This sounds a little dangerous though as I don't think that we'd want people to pretend to be other people. 

If I have a line of commits by alice and bob that goes

Alice(1a) -> bob(1b) -> Alice(1c) -> bob(2c)

when bob pushes 2c back to master - I want reviews raised for 1a to 1c, but would be nice if it was clear that these were really raised because bob pushed {perhaps via a comment on the review}

I get that the two are not separable though; thanks again for the response David.

Cheers

-ace

[Thomas Swindells (tswindel)]

Once the work has been done the other option is to have the commit to squash the commits into a single new change and submit that onto master instead.

It means everything can be reviewed as a single change and detaches the change from the branch history (making master’s history ‘cleaner’). Depending on your use case and point of view both of these side effects can either be positives or negatives.

 

Thomas

 

--
--
To unsubscribe, email repo-discuss...@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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ace Chandler]

Thanks Thomas - We'd considered that option but are concerned about loss of granularity and fidelity. 

Realize that we basically we want to have our cake and eat it. That is:

-Preserve the fidelity  of master branch - so that we can see who made all of the commits (no squashing)

-Not permit forging

-Allow people to integrate quickly from review-less (scratch) feature branches into master

Thanks again for all the responses.

-ace

--
--
To unsubscribe, email repo-discus...@googlegroups.com

[Sascha Vogt]

Hi Ace,

Am 22.10.2013 14:49, schrieb Ace Chandler:
> Thanks Thomas - We'd considered that option but are concerned about loss
> of granularity and fidelity.
>
> Realize that we basically we want to have our cake and eat it. That is:
>
> -Preserve the fidelity of master branch - so that we can see who made
> all of the commits (no squashing)
> -Not permit forging
> -Allow people to integrate quickly from review-less (scratch) feature
> branches into master

If user-a uploads the whole branch, he also therefore uploads changes
done by user-b. He is therefore in fact "forging user-b"'s identity,
because he uploads changes on behalf of user-b. So why don't you want to
permit forging?

Greetings
-Sascha-