How to commit changes to the branch only with approval in gerrit?
Baz
banana% git checkout master
banana% git merge topic-branch
banana% git push origin master
banana% git push gerrithost master
Magnus Bäck
Baz <bazt...@gmail.com> wrote:
> I am still trying to understand the correct usage or gerrit in our
> development environment... Going back to the example from
> http://unethicalblogger.com/2009/12/07/code-review-with-gerrit-a-mostly-visual-guide.html
>
> The last few lines after approvals in Gerrit...
>
> banana% git checkout master
> banana% git merge topic-branch
> banana% git push origin master
> banana% git push gerrithost master
Let's stop here, because this is very weird workflow that isn't
well explained in the blog. The standard way of submitting a change
is by pressing the "Submit Patch Set" button in the web UI. Gerrit
will merge the change for you and then you're done.
The default permissions of Gerrit won't allow anyone to push code
directly to branches without having them go through review (i.e.
they can only push to refs/for/xxx and not refs/heads/xxx).
[...]
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
Marciano Pitargue
I'm currently playing w/ version 2.1.6.1. Where exactly is the "Submit Patch Set" button?
Marciano
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
Magnus Bäck
Marciano Pitargue <kct...@motorola.com> wrote:
> I'm currently playing w/ version 2.1.6.1. Where exactly is the
> "Submit Patch Set" button?
It's right by the other buttons (Publish Comments, Abandon,
Diff All Side-by-Side, ...), but it'll only be shown if the
change is submittable, i.e. if the latest patch set has been
scored Verified +1, Code Review +2, and has no other blocking
scores (like a Code Review -2).
R. Tyler Croy
On Fri, 08 Jul 2011, Magnus B?ck wrote:
> On Friday, July 08, 2011 at 18:22 CEST,
> Marciano Pitargue <kct...@motorola.com> wrote:
>
> > I'm currently playing w/ version 2.1.6.1. Where exactly is the
> > "Submit Patch Set" button?
>
> It's right by the other buttons (Publish Comments, Abandon,
> Diff All Side-by-Side, ...), but it'll only be shown if the
> change is submittable, i.e. if the latest patch set has been
> scored Verified +1, Code Review +2, and has no other blocking
> scores (like a Code Review -2).
I wrote the original blog post referenced here, I need to post an addendum now
that I've learned a bit more :)
At the time I wasn't using replication, my preferred workflow now is to push to
Gerrit, submit there and have Gerrit replicate to the upstream repository.
Cheers
- R. Tyler Croy
--------------------------------------
Code: http://github.com/rtyler
Chatter: http://identi.ca/agentdero
http://twitter.com/agentdero
Baz
Magnus Bäck
Baz <bazt...@gmail.com> wrote:
> Any advice?
I responded last week, about nine hours after your post. If my advice
didn't help I'd like to know why.
Baz
Marciano Pitargue
Marciano
Marciano Pitargue
Thanks. I'll have to play with this a bit more.
Marciano
Baz
On Monday, July 11, 2011 at 21:34 CEST,
> Magnus, sorry, I didnt see your reply in any of my email archive.
> would you please resend it? Thank you. B.
Attaching the original message, which you can respond to in order to
keep the threading intact. The message is of course also available in
the list archives (http://goo.gl/55CqT).
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
---------- Forwarded message ----------
From: Magnus Bäck <magnu...@sonyericsson.com>
To: repo-d...@googlegroups.com
Date: Fri, 8 Jul 2011 08:25:45 +0200
Subject: Re: How to commit changes to the branch only with approval in gerrit?
On Thursday, July 07, 2011 at 23:49 CEST,
Baz <bazt...@gmail.com> wrote:
> I am still trying to understand the correct usage or gerrit in our
> development environment... Going back to the example from
> http://unethicalblogger.com/2009/12/07/code-review-with-gerrit-a-mostly-visual-guide.html
>
> The last few lines after approvals in Gerrit...
>
> banana% git checkout master
> banana% git merge topic-branch
> banana% git push origin master
> banana% git push gerrithost master
Let's stop here, because this is very weird workflow that isn't
well explained in the blog. The standard way of submitting a change
is by pressing the "Submit Patch Set" button in the web UI. Gerrit
will merge the change for you and then you're done.
The default permissions of Gerrit won't allow anyone to push code
directly to branches without having them go through review (i.e.
they can only push to refs/for/xxx and not refs/heads/xxx).
[...]
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
R. Tyler Croy
On Mon, 11 Jul 2011, Baz wrote:
> I am really dumb here... Where is "Submit Patch Set"? I cannot find it.
>
> Do I suppose to open the change, then review it and give it a "+2", then
> what should I do? In the blog from my original post, I suppose to go back to
> my workspace, then merge the changes from temp branch to master, then push
> it back to origin. Is it correct? (not going through UI).
You won't find the "Submit" buttons on the changeset's page unless your user
has the appropriate Submit permissions for the project.
Martin Fick
> I am really dumb here... Where is "Submit Patch Set"? I
> cannot find it.
>
> Do I suppose to open the change, then review it and give
> it a "+2", then what should I do? In the blog from my
> original post, I suppose to go back to my workspace,
> then merge the changes from temp branch to master, then
> push it back to origin. Is it correct? (not going
> through UI).
It sounds like the blog actually bypassed Gerrit in its
workflow. Until it is updated, you might be better off
sticking to the Gerrit docs?
You likely need to mark the change Verified before
you will see the submit button.
-Martin
Baz
You have likely code reviewed it +2, verified is usually a +1. You may not see the ability to add +1 verified unless you have given your group verified permission.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.Baz <bazt...@gmail.com> wrote:Hi,
I added submit permission and I do see the button "Submit Patch Set 1".
But when I push it, I see "Application Error, Server Error, Requires Verified".
I do not see any errors in the error_log.
Any ideas?
Thanks.
B.
I have verified the change with "+2". Is the error caused because I need another reviewer other than myself?2011/7/11 Martin Fick <mf...@codeaurora.org>
Martin Fick
Verified. Someone needs permissions for each, and each must
be given. Then whoever has submit permissions can submit.
-Martin
On Tuesday 12 July 2011 10:31:36 am Baz wrote:
> Yes, you are correct. I thought I need to approve it with
> +2 in order to "submit"? No? What should I do to submit
> that change?
>
> On Tue, Jul 12, 2011 at 7:08 AM, Martin Fick
<mf...@codeaurora.org> wrote:
> > ** You have likely code reviewed it +2, verified is
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
Baz
I have made the change, reviewed the change, verified it (+1) and approved it (+2) as me (administrator). When pressing "Submit Patch Set 1", I still have the error message "Application Error, Server Error, Requires Verified".
Am i still missing something?
Saša Živkov
Sorry if I am slow in understanding the documentation and the simple workflow.
I have made the change, reviewed the change, verified it (+1) and approved it (+2) as me (administrator). When pressing "Submit Patch Set 1", I still have the error message "Application Error, Server Error, Requires Verified".
Please check the <review-site>/logs/error_log file for this error and post the stack trace here.
Am i still missing something?
Baz
There is only entry in httpd_log:
10.1.3.106 - username [12/Jul/2011:09:55:16 -0700] "POST /gerrit/rpc/ChangeManageService HTTP/1.1" 200 79 "http://hostname.companyname.com:8080/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1"
Martin Fick
like you only gave it +1.
--
Baz
In the UI, mid section:
Reviewer Verified Code Review
USER_FULL_NAME
+1 Looks good to me, but someone else must approve
Need Verified +1 (Verified)
Need Code Review +2 (Looks good to me, approved)
Bottom section:
Comments
Expand RecentExpand AllCollapse All
USER_FULL_NAME Patch Set 1: Looks good to me, approved Jul 11
USER_FULL_NAME Patch Set 1: Looks good to me, but someone else must approve 9:45 AM
USER_FULL_NAME Patch Set 1: Looks good to me, approved Approved. 10:24 AM
USER_FULL_NAME 10:24 AM
Patch Set 1: Looks good to me, but someone else must approve
Martin Fick
> USER_FULL_NAME ...but someone else must approve
> USER_FULL_NAME ... approved
> USER_FULL_NAME ... but someone else must approve
Are those the same users? The last setting for a particular
approver overrides their previous settings. If you can't
divulge usernames, could you use X/Y...
-Martin
Baz
Baz
Martin Fick
> I can definitely review the change then assign verified
> (+1) or approved (+2), but when I push the button
> "Publish and Submit", I will have the same application
> error.
>
> On Tue, Jul 12, 2011 at 11:02 AM, Baz
<bazt...@gmail.com> wrote:
> > Yes, all the same user - me. There is only one user in
> > the gerrit right now.
> >
> >
> > 2011/7/12 Martin Fick <mf...@codeaurora.org>
> >
> >> > USER_FULL_NAME ... approved
> >> > USER_FULL_NAME ...but someone else must approve
> >> > USER_FULL_NAME ... approved
> >> > USER_FULL_NAME ... but someone else must approve
The last line here removes the approved, you need to add it
again (it downgrades a +2 to a +1).
Baz
Status should be approved but I still have the application error. The updated look like this:
Comments
Expand RecentExpand AllCollapse All
USER_FULL_NAME Patch Set 1: Looks good to me, approved Jul 11
USER_FULL_NAME Patch Set 1: Looks good to me, but someone else must approve 9:45 AM
USER_FULL_NAME Patch Set 1: Looks good to me, approved Approved. 10:24 AM
USER_FULL_NAME Patch Set 1: Looks good to me, but someone else must approve VERIFIED. 10:24 AM
USER_FULL_NAME Patch Set 1: Looks good to me, approved Again. 11:13 AM
USER_FULL_NAME Patch Set 1: Looks good to me, but someone else must approve 11:14 AM
USER_FULL_NAME 11:14 AM
Patch Set 1: Looks good to me, approved
<sorry I hit the reply too soon>
Martin Fick
On Tuesday 12 July 2011 01:46:13 pm Baz wrote:
> Status should be approved but I still have the
> application error. The updated look like this:
>
> Comments
> Expand RecentExpand AllCollapse All
> USER_FULL_NAME Patch Set 1: Looks good to me, approved
> Jul 11 USER_FULL_NAME Patch Set 1: Looks good to
> me, but someone else must approve 9:45 AM
> USER_FULL_NAME Patch Set 1: Looks good to me, approved
> Approved. 10:24 AM
> USER_FULL_NAME Patch Set 1: Looks good to me, but
> someone else must approve VERIFIED. 10:24 AM
> USER_FULL_NAME Patch Set 1: Looks good to me, approved
> Again. 11:13 AM USER_FULL_NAME Patch Set 1: Looks
> good to me, but someone else must approve 11:14 AM
> USER_FULL_NAME 11:14 AM
> Patch Set 1: Looks good to me, approved
It is hard to tell from this list if the VERIFIED was
overridden at some point. What do you see when you go to
review the patch? Which buttons are prechecked for you?
I know I am grasping at straws here, but your error message
seem to clearly indicate that you have not properly verified
the change,
-Martin
Baz
Code review section:
"+1 Looks food to me, but someone else must approve" is checked.
Three buttons are available:
- Publish Comments
- Publish and Submit
- Cancel
If I check "+2 Looks good to me, approved", add a "cover message" "Test again", hit "Publish and Submit", then I will get the same application error.
Martin Fick
On Tuesday 12 July 2011 04:58:41 pm Baz wrote:
> When I click review button for the "Patch Set 1", I see:
>
> Code review section:
> "+1 Looks food to me, but someone else must approve" is
> checked.
>
> Three buttons are available:
> - Publish Comments
> - Publish and Submit
> - Cancel
>
> If I check "+2 Looks good to me, approved", add a "cover
> message" "Test again", hit "Publish and Submit", then I
> will get the same application error.
Right, because you still need a +1 Verified. This is a completely different category from Code Review.
You need to see:
Verified:
Code Review:
Cover Message:
Then, you can submit. If you don't see the Verified section at all, then you haven't given yourself verified permissions via the access controls,
-Martin
Baz
Baz
Once I have "Verified +1" and "Code review +2", then I hit "Publish and Submit". No error.
Press "Submit Patch Set 1" button, I have the following errors:
Submit Failed
Change cannot be merged due to unsatisfiable dependencies.
The following dependency errors were found:
- Depends on commit <blah> which has no change associated with it.
- Depends on commit <blah2> which has no change associated with it.
Please rebase the change and upload a replacement commit.
Martin Fick
> The following dependency errors were found:
> - Depends on commit <blah> which has no change associated
> with it. - Depends on commit <blah2> which has no change
> associated with it. Please rebase the change and upload
> a replacement commit.
You change depends on changes which are not either changes
themselves, or not already merged to the head. Gerrit will
not allow such changes to be merged (since it would mean
bringing in code which bypassed code review). You need to
"fix" this. Structure your change as a single commit, or as
a series of single commit changes.
-Martin
Baz
However, I do not understand why the error in the first place. It is a test repo that nobody with touch that specific file.
Baz
I dont think it is depending on another branch since this is the only branch (master) and it is a test branch.
What is the best way that i test it now? Go back to my workspace, update, make another change? What should I do in real life situation?
On Tuesday 12 July 2011 05:44:03 pm you wrote:
> Can i try abandon the change, update and make the change
> again? Since this is just a test of the workflow, it
> should be ok right?
The is no point in abandoning, that's what ChangIds are for,
so that you can just upload a new patchset.
> However, I do not understand why the error in the first
> place. It is a test repo that nobody with touch that
> specific file.
Perhaps your changes depend on changes in another branch?
-Martin
Baz
Let me re-run the process again...
A. Install Gerrit.
B. Initialize the project from existing project. (I am not sure if this is the best init process since it re-checkin everything from the existing repo to the project in gerrit, comments?)
2. In my local machine, I performed "git clone git:/repos/test_project.git test_project.git.
3. cd test_project.git.
4. git checkout master.
5. git remote add gerrithost ssh://username@hostname:29418/test_project.git.
C. To clone repo from Gerrit:
- git clone ssh://username@hostname:29418/test_project.git test_project
D. Work on the changes locally:
- cd test_project
- <edit files>
- git commit -a
E. Push changes back to Gerrit:
- git push origin HEAD:refs/for/master
F: Review and approve changes in Gerrit:
- Someone to review and mark the change to "verified +1" and "code review +2".
G. Merge approved changes from "topic-branch" to master locally:
- git checkout master
- git merge "topic-branch"
H. Push changes back to origin. Changes are now available to others if they decided to clone from git:/repos/test_project.git
- git push origin master
I. Push changes to Gerrit. Changes made now becomes "merged"
- git push gerrithost master
According to this email thread, I should be able to replace step G, H, I by pressing "Submit Patch Set 1". Am i correct? Is this the proper workflow?
Thanks.
B.
Magnus Bäck
Baz <bazt...@gmail.com> wrote:
> So, here are my questions before I restart the test, am i using the
> right process? I mostly follow the process in
> http://unethicalblogger.com/2009/12/07/code-review-with-gerrit-a-mostly-visual-guide.html.
> ..
>
> Let me re-run the process again...
[...]
> G. Merge approved changes from "topic-branch" to master locally:
> - git checkout master
> - git merge "topic-branch"
>
> H. Push changes back to origin. Changes are now available to others if
> they decided to clone from git:/repos/test_project.git
> - git push origin master
>
> I. Push changes to Gerrit. Changes made now becomes "merged"
> - git push gerrithost master
>
> According to this email thread, I should be able to replace step G, H,
> I by pressing "Submit Patch Set 1". Am i correct? Is this the proper
> workflow?
Yes, that's the standard workflow. Gerrit does recognize when you push
straight to the branch and will mark those open changes as merged, but
it just seems overly complicated.
Baz
Baz
Martin Fick
--
Baz
Change could not be merged because of a missing dependency.
The following changes must also be submitted:
I5f6320e5ea42cc6837e693ec8d66db976095e930
Baz
So, my question now is: All the changes from local workspace pushed to Gerrit, but when I start a fresh workspace from another machine, I do not see those changes. Why? Are they sitting in Gerrit and need someone to push the changes back to the origin from gerrit's cloned repo?
Torne Wuff
> The change marked "SUBMITTED" now being "MERGED".
>
> So, my question now is: All the changes from local workspace pushed to
> Gerrit, but when I start a fresh workspace from another machine, I do not
> see those changes. Why? Are they sitting in Gerrit and need someone to push
> the changes back to the origin from gerrit's cloned repo?
I think you are missing a major point with how Gerrit works; the
expectation is that the repository in Gerrit *is* the main repository,
not just a clone of it. People should be creating clones directly from
Gerrit.
--
Torne Wuff
to...@wolfpuppy.org.uk
Baz
Just to repeat my case:
1. There is an existing repo git:/repos/test_project.git from server A.
2. I installed gerrit in server B and init a project called test_project.git via the ssh command as instructed from the documentation.
3. I filled test_project.git in gerrit with the existing project test_project.git.
- Right now, I have two methods being suggested. a) Use "git clone --bare" test_project.git at gerrit server B from test_project.git from A. b) Clone test_project.git from server A into local workspace and commit all the changes into test_project.git in gerrit in server B. Which one is correct? Is there another method?
Torne, and all, so are you saying that once a change become "merged" status, thats the end of the workflow? Meaning, I do not need to push the changes back to origin?
Torne Wuff
> Ah, so i wonder too. This is something that I am really missing and need
> experienced gerrit users to tell me...
>
> Just to repeat my case:
>
> 1. There is an existing repo git:/repos/test_project.git from server A.
>
> 2. I installed gerrit in server B and init a project called test_project.git
> via the ssh command as instructed from the documentation.
>
> 3. I filled test_project.git in gerrit with the existing project
> test_project.git.
> - Right now, I have two methods being suggested. a) Use "git clone --bare"
> test_project.git at gerrit server B from test_project.git from A. b) Clone
> test_project.git from server A into local workspace and commit all the
> changes into test_project.git in gerrit in server B. Which one is correct?
> Is there another method?
The quick way here would be to just copy the repository itself from
server A into gerrit's git directory (using scp or similar, not git).
You would then shut down the repository on server A and have everyone
work solely using the gerrit repository on server B instead. Gerrit
*is* a git server, you don't need another server as well. You can do
it by either of the methods you suggested too, but the important step
is to *stop using the original server afterward*. Gerrit workflows
assume that the repository hosted by gerrit is the main repository for
the project.
> Torne, and all, so are you saying that once a change become "merged" status,
> thats the end of the workflow? Meaning, I do not need to push the changes
> back to origin?
Yes, the normal workflow is that gerrit merges the change into its
local copy of refs/heads/master (or whichever branch) and then that's
it. For everyone else, gerrit *is* their origin repository. The next
time they update their remotes/origin/master will contain those
changes, because origin is the gerrit server.
--
Torne Wuff
to...@wolfpuppy.org.uk
Baz
Just to be cleared, is gerrit - the final destination of the change workflow a common practice?
Martin Fick
that is why everyone has told you not to use it until it is
updated.
--
Baz
Ed C
might be worth considering why someone starts with an out dated and
non-standard practice blog post rather than the docs.
When I first started playing with gerrit I also found & followed that
post because it seemed like a nice simple example walkthrough. The
gerrit docs are a good reference but they lack that simple tutorial /
walkthrough that people look for to decided if a tool will work in
their organisation.
I think we can probably avoid threads like this one and help the
adoption of gerrit if we have such an intro doc which shows how gerrit
would fit in and be used.
I can take a first stab at this if someone who has a better grasp of
real world gerrit usage is able to review it. What is the process for
contributing docs? I see ASCII doc mentioned, is this the satndard? Do
the docs source just live in the gerrit source and get reviewed in the
same way as code?
Cheers
Ed
Sent from my iPod
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
Martin Fick
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Baz
Honestly, for a beginner like me (as well as a couple of guys that I talked to... and we are pretty technical), we think the gerrit manual is hard to follow. Simple tutorial and walkthrough are good ideas.
Thank you for doing this.
What about suggested subjects?
Ed C
Ed C
https://review.source.android.com/24789
This really is a first cut. I have yet to proof read it so I've self -1'd it as it should not be submitted in current form. What i would like at this point is feedback on whether this is the kind of documentation that would be useful.
That said, any feedback on correctness, style, spelling or pretty much anything else is welcome.
Cheers
Ed
Steffen Gebert
thanks for your work on the tutorial!
We also created a (bit customized) tutorial for TYPO3, which is available here:
http://wiki.typo3.org/Contribution_Walkthrough_with_CommandLine
Maybe it gives you some inspiration. We tried to keep the guide very short, to not scare possible contributors with huge amount of text.
Kind regards
--
Steffen Gebert
TYPO3 v4 Core Team Member
TYPO3 Server Administration Team Member
TYPO3 .... inspiring people to share!
Get involved: http://typo3.org
Ed C
audiences. I actually think we need both in the Gerrit docs:
* a quick practicle guide for people wanting to submit, review or try
out a change
* a more in depth intro to how gerrit works and how for people trying
to decide if it is the right tool for their project / organisation.
I've been targeting this second case I really must rename the doc from
it's working title of "a quick introduction", it's becomming
increasingly inaccurate.
I think the typo3 tutorial is a great inspiration for the first case
( tell me what to do and get out the way). I'm not sure if the open
content license is sufficiently compatible with the license of Gerrit
docs (I assume apache2 like the code) to allow a derived work to be
included. But something similar is definately needed.
Cheers
Ed
On Jul 24, 2011, at 12:40 AM, Steffen Gebert <steffen@steffen-