"+1" plus "+1" = 2

1808 views
Skip to first unread message

marksta

unread,
Feb 2, 2012, 8:42:56 AM2/2/12
to Repo and Gerrit Discussion
Dear gerrit group

We would like to give every developer review permissions for +1 and I
would like gerrit to merge as soon as there are two +1.

I couldn't find anything useful yet, so any help is appreciated.

Thanks & best regards
Markus

Shawn Pearce

unread,
Feb 2, 2012, 10:10:20 AM2/2/12
to marksta, Repo and Gerrit Discussion
On Thu, Feb 2, 2012 at 05:42, marksta <mar...@4eyes.ch> wrote:
> We would like to give every developer review permissions for +1 and I
> would like gerrit to merge as soon as there are two +1.
>
> I couldn't find anything useful yet, so any help is appreciated.

Unfortunately scores are not additive right now. This is a great idea
feature-wise, and it may be able to be done with the Prolog
interpreter in 2.2.2 using a rules.pl inside of the project
repository. Unfortunately nobody has tried writing such a rule yet.
:-)

Martin Fick

unread,
Feb 2, 2012, 12:09:49 PM2/2/12
to repo-d...@googlegroups.com
On Thursday, February 02, 2012 06:42:56 am marksta wrote:
> Dear gerrit group
>
> We would like to give every developer review permissions
> for +1 and I would like gerrit to merge as soon as there
> are two +1.

I think that if you made the CR category only range up to
+1, then you could remove submit from all users except for a
special hook user, and then make the comment-added hook
perform the submit when it sees the second +1.

-Martin

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

Markus Stauffiger

unread,
Feb 3, 2012, 5:43:53 AM2/3/12
to Repo and Gerrit Discussion
Ok, thank both of you for your tipps! :)

Johan Björk

unread,
Feb 5, 2012, 12:21:34 PM2/5/12
to Markus Stauffiger, Repo and Gerrit Discussion
Hi,

I've done some experimentation with the prolog rules in gerrit today
and one of the things I implemented was the 1+1 = 2 rule.

Here is some notes from the session + rules for the 1+1=2.
Gerrit 2.2 Prolog rules
-----------------------

First off, this is the result of a couple of hours of experimenting,
so expect potentially incorrect information.
Shawn, please correct me if I'm making some invalid assumptions.

Introduction:
Gerrit 2.2 now supports special submit rules written in prolog. You
can enable it for a project by checking out the refs/meta/config
branch and pushing a file called 'rules.pl'.

git clone <your project>
git fetch origin refs/meta/config
git checkout -b config FETCH_HEAD
git add rules.pl ; git commit...
git push origin config:refs/meta/config


===Basics===
Each project can have their own rules.pl together with a submit_rule
predicate. It seems you can also have a submit_filter predicate that
takes in the previously set results and modify them, ie, in
all-projects or something like that, but I haven't tested that.

The submit_rule takes one 'argument' and you need to fill it in with
the form submit(label(name,status),label(name,status),...)
You can name the labels anything you want, but if your users should be
able to score them, they need to be created in the database like the
old review categories. (Anyone know if that is correct?)

I haven't found a way to set a review-score through the prolog
scripts, nor a good way to communicate to users, but I guess it's not
really intended for that.

So what can you do? Lots of data is exposed: commit message, all the
files that have been modified, author, etc etc. This is pretty well
documented in the 2.2.2 release notes.

*Warning*: Once you create a rules.pl file, the old legacy rules will
not be used!

== Example 1+1 = 2 ==
The rule allows submit if the accumulated score of the review is at
least 2. Ie, one +2 or two +1's.


%% rules.pl.
%% Allow submit if there is a total of +2 in review 'scores' (accumulative)
%% This file is an example to learn about prolog submit checkers
%%
:- package user.

%% Result returned from submit_label should be something like
%% submit(label(name,status),label(name,status),...)
%% Status can be either ok(_), reject(_), need(_) or impossible(_)
%% ok() and reject() takes a user id as their argument, but I dont
know how that is used.

sum_list([], 0).
sum_list([H | Rest], Sum) :- sum_list(Rest,Tmp), Sum is H + Tmp.

check_min_label(Category, Min, P) :-
findall(X, gerrit:commit_label(label(Category,X),_),Z),
sum_list(Z, Sum),
( Sum >= Min -> P =.. [label,Category,ok(Who)]
; P =.. [label,Category,need(Min)]
).

% This is the function that will be invoked by gerrit. We call the
check_plus2 function and returns a function submit(...)
% which gerritalways expects. (See gerrit_common.pl:133)
submit_rule(P) :- check_min_label('Code-Review', 2, HasPlusTwo),
P =.. [submit, HasPlusTwo].

=== How to test ===
Upload a change for review, then keep pushing changes to rules.pl
until it does what you want. A simple re-load on the project page will
directly use the updated rules.pl

(There is a built-in interpreter, but I haven't been able to properly
load both gerrit_common.pl together with a rules.pl (Shawn?). I did
manage to test rules locally by adding
%Test submit_rule
x_can_submit(SubmitRule, S) :-
submit_rule(Tmp),
Tmp =.. [submit | Ls],
( is_all_ok(Ls) -> S = ok(Tmp), ! ; S = not_ready(Tmp) ).

is_all_ok([]).
is_all_ok([label(_, ok(__)) | Ls]) :- is_all_ok(Ls).
is_all_ok(_) :- fail.
to my rules.pl)

but that won't work once you try to use the gerrit builtin predicates.

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

Shawn Pearce

unread,
Feb 6, 2012, 9:59:06 AM2/6/12
to Johan Björk, Markus Stauffiger, Repo and Gerrit Discussion
[resend +repo-discuss]

On Sun, Feb 5, 2012 at 09:21, Johan Bj=F6rk <p...@spotify.com> wrote:
> I've done some experimentation with the prolog rules in gerrit today

> and one of the things I implemented was the 1+1 =3D 2 rule.

Thanks for posting this!

> Here is some notes from the session + rules for the 1+1=3D2.


> Gerrit 2.2 Prolog rules
> -----------------------
>
> First off, this is the result of a couple of hours of experimenting,
> so expect potentially incorrect information.
> Shawn, please correct me if I'm making some invalid assumptions.
>
> Introduction:
> Gerrit 2.2 now supports special submit rules written in prolog. You
> can enable it for a project by checking out the refs/meta/config
> branch and pushing a file called 'rules.pl'.
>

> =A0git clone <your project>
> =A0git fetch origin refs/meta/config
> =A0git checkout -b config FETCH_HEAD
> =A0git add rules.pl ; git commit...
> =A0git push origin config:refs/meta/config

This is awkward to test with, as you note below. We should try to
improve this with a way to run these rules locally in a test
environment. Jason Tsay (my intern last summer that did a lot of this
work) suggested doing this, but had to return to university before he
could get to this. I proposed it wasn't super critical, because
administrators could set up a small H2 based test server locally to
kick around the rules on before pushing them to their production
server. Despite having that, it would be good to have a faster way to
test these.

More complex rules may also want a unit test framework.

> =3D=3D=3DBasics=3D=3D=3D


> Each project can have their own rules.pl together with a submit_rule
> predicate. It seems you can also have a submit_filter predicate that
> takes in the previously set results and modify them, ie, in
> all-projects or something like that, but I haven't tested that.

Yes. Parent projects (all the way up to All-Projects) can use
submit_filter to process the results of a child project and enforce
higher level policies. One example usage of this is a system wide rule
to require a release engineer to approve any change going to a frozen
release branch.

> The submit_rule takes one 'argument' and you need to fill it in with
> the form submit(label(name,status),label(name,status),...)
> You can name the labels anything you want, but if your users should be
> able to score them, they need to be created in the database like the
> old review categories. (Anyone know if that is correct?)

Correct. The range of potential values must come from the
approval_category_values table in the database, which means you must
also declare the label with a row in the approval_categories table.
Since the default submit rules require all of the declared
approval_categories to be satisfied to submit a change, creating a new
optional category for the Prolog rules to use in a project is awkward.
You also have to create a submit_filter in All-Projects that makes
this optional.

> I haven't found a way to set a review-score through the prolog
> scripts,

You cannot set a score through Prolog. The current system is designed
to be pure functions, with no side-effects. I never anticipated
setting scores in Prolog, I assumed the Prolog logic would decide what
labels need to be set. If the logic doesn't want to require
Code-Review +2 before submit, it can just not include the Code-Review
label in the submit compound term it returns. Or as you do where with
the "sum to 2" rule, export it as ok once its happy.

> nor a good way to communicate to users, but I guess it's not
> really intended for that.

Right now the only communication with a user is the few status codes
you found to export: ok, reject, need, impossible. The first 3 are the
common results:

ok - This label/category's rule has been met. If all
label/categories are ok the change can submit.
reject - A score is blocking submission, aka "Verified -1" or
"Code-Review -2".
need - If the right user(s) set the right scores it can be submitted.

impossible - The logic knows the change cannot be submitted as-is.
Administrative intervention is probably required. This is meant for
cases where the logic requires members of "FooEng" to score
"Code-Review +2" on a change, but nobody is in group "FooEng". It is
to hint at permissions misconfigurations.

> So what can you do? Lots of data is exposed: commit message, all the
> files that have been modified, author, etc etc. This is pretty well
> documented in the 2.2.2 release notes.
>
> *Warning*: Once you create a rules.pl file, the old legacy rules will
> not be used!

This should only happen if you declare the submit_rule predicate, or
submit_filter in a parent project. Of course that is the reason to
create this file. :-)

> =3D=3D Example 1+1 =3D 2 =3D=3D


> The rule allows submit if the accumulated score of the review is at
> least 2. Ie, one +2 or two +1's.
>
>
> %% rules.pl.

> %% Allow submit if there is a total of +2 in review 'scores' (accumulativ=


e)
> %% This file is an example to learn about prolog submit checkers
> %%
> :- package user.
>
> %% Result returned from submit_label should be something like
> %% submit(label(name,status),label(name,status),...)
> %% Status can be either ok(_), reject(_), need(_) or impossible(_)
> %% ok() and reject() takes a user id as their argument, but I dont
> know how that is used.

I don't think the Who is actually used in the Java server. I meant to
eventually export this to the UI, especially the reject(Who) case to
say something in the UI like "Submission blocked by Dr. Who". Then the
change owner can try to work out with Dr. Who why they blocked the
change. Maybe its because they are playing the role of Dr. No for this
release and have said "No, this change is too risky for this release".
:-)

> sum_list([], 0).
> sum_list([H | Rest], Sum) :- sum_list(Rest,Tmp), Sum is H + Tmp.
>

> check_min_label(Category, Min, =A0P) :-


> findall(X, gerrit:commit_label(label(Category,X),_),Z),
> sum_list(Z, Sum),

> ( Sum >=3D Min -> P =3D.. [label,Category,ok(Who)]
> =A0; P =3D.. [label,Category,need(Min)]
> =A0).

This is a bit awkward to use =3D.., can't you say:

( Sum >=3D Min -> P =3D label(Category, ok(Who))
; P =3D label(Category, need(Min))
).

I usually prefer to write these sorts of rules with a couple of cases
rather than using ->;

check_min_label(Category, Min, P) :-
findall(X, gerrit:commit_label(label(Category, X), _), List),
sum_list(List, Sum),
Sum >=3D Min,
P =3D label(Category, ok(_)).

check_min_label(Category, Min, P) :-
P =3D label(Category, need(Min)).

> % This is the function that will be invoked by gerrit. We call the
> check_plus2 function and returns a function submit(...)
> % which gerritalways expects. (See gerrit_common.pl:133)
> submit_rule(P) :- check_min_label('Code-Review', 2, HasPlusTwo),

> P =3D.. [submit, HasPlusTwo].

Again, you can use P =3D submit(HasPlusTwo). =3D.. is mainly useful for
dynamic situations where you have a list of arguments for the compound
and you don't know when you wrote the code how many arguments you
need.

We us a compound here because you can then write your submit rule like this=
:

submit_rule(submit(CodeReview)) :-
check_min_label('Code-Review', 2, CodeReview).

submit_rule(submit(CodeReview, ManagerOverride)) :-
check_min_label('Code-Review', 1, CodeReview),
check_min_label('Manager-Override', 1, ManagerOverride).

In experimentations I found it cleaner to write in the submit rule
predicate the exact categories I wanted this rule to require/enforce,
and then use variables for each of them in the body of the rule. The
two cases above say you can submit a change if you have 1+1=3D2 for
Code-Review, OR if you have 1 Code-Review and 1 Manager-Override. This
prevents 2 Manager-Overrides from making the change submittable. OK,
maybe this is a contrived example since the manager could be giving
Code-Review... but perhaps it is worthwhile to declare this exemption
as its own category.

Another might be to require ThirdParty review on files in third_party/
directory:

submit_rule(submit(CodeReview, ThirdParty)) :-
gerrit:commit_delta('^third_party/.*'),
!,
check_min_label('Code-Review', 2, CodeReview),
check_min_label('ThirdParty-Review', 1, ThirdParty).

submit_rule(submit(CodeReview)) :-
check_min_label('Code-Review', 2, CodeReview).

The ! is necessary in that first rule to cut off the other possible
ways to complete the change. Without it the server can backtrack and
choose the second case, permitting submission without the
ThirdParty-Review flag even if there is a path touched under
third_party/.

This is the real power of using a Prolog interpreter for the rule
evaluation, but its also the risk... it will backtrack. :-)

> =3D=3D=3D How to test =3D=3D=3D


> Upload a change for review, then keep pushing changes to rules.pl
> until it does what you want. A simple re-load on the project page will
> directly use the updated rules.pl
>
> (There is a built-in interpreter, but I haven't been able to properly
> load both gerrit_common.pl together with a rules.pl (Shawn?).

Not supported at this time. The problem is gerrit_common.pl requires a
huge amount of the server environment to be loaded and running,
complete with database and Git repository and an active user. I
mentioned above we would like to extend this to be a test environment
that is just like the real server, but it was difficult to setup and
my intern ran out of time during his internship to finish that work.

It might be possible to setup a mock environment using an in-memory H2
database and some in-memory Git repositories, but then you have to
worry about setting up the test change data too. What data you want in
the test change(s) and how the projects are put together in a parent
project hierarchy is difficult. So we punted. I told Jason most server
administrators keep test servers that have restored backups of their
organizations real servers (OK, I at least did that with rsac and the
internal Google server!), so any testing would be done on one of
those.

Trevor Vaughan

unread,
Feb 2, 2012, 10:06:47 AM2/2/12
to Repo and Gerrit Discussion
+1 on this.

I was trying to figure this out earlier and it just doesn't seem
possible at this point.

Thanks,

Trevor

Trevor Vaughan

unread,
Feb 2, 2012, 1:53:40 PM2/2/12
to repo-d...@googlegroups.com
There doesn't appear to be a way to get this information out of the
gerrit query command that I can find.

I suppose that it could be dug out of the SQL but that's a bit heavyweight.

Any pointers on how to actually find this information via gerrit (if
possible) would be appreciated.

Thanks,

Trevor

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

Bruce Zu

unread,
Mar 15, 2012, 5:42:05 AM3/15/12
to repo-d...@googlegroups.com, Johan Björk, Markus Stauffiger
Gerrit Code Review 2.2.2

1> 'push origin config:refs/meta/config  '  get feedback 'error: src refspec config does not match any.'

2> 'push origin config:refs/meta/config'    get feedback ' ! [remote rejected] HEAD -> refs/meta/config (can not update the reference as a fast forward)
error: failed to push some refs to ...'  

3>'push origin config:refs/heads/refs/meta/config'     success however new branch created  '* [new branch]      HEAD -> refs/for/refs/meta/config'

is this what we expected ? seems a bug is here

/Bruce

Magnus Bäck

unread,
Mar 15, 2012, 7:18:49 AM3/15/12
to repo-d...@googlegroups.com
On Thursday, March 15, 2012 at 05:42 EDT,
Bruce Zu <zu.bruc...@gmail.com> wrote:

> Gerrit Code Review 2.2.2
>
> 1> 'push origin config:refs/meta/config ' get feedback 'error: src
> refspec config does not match any.'

Did you have a ref named "config" in your workspace?

> 2> 'push origin config:refs/meta/config' get feedback ' ! [remote
> rejected] HEAD -> refs/meta/config (can not update the reference as a
> fast forward)
> error: failed to push some refs to ...'

Was your commit based on the tip of refs/meta/config? If not, this error
message is expected.

> 3>'push origin config:refs/heads/refs/meta/config' success however
> new branch created '* [new branch] HEAD -> refs/for/refs/meta/config'

Um, this isn't consistent. You're saying you pushed to
refs/heads/refs/meta/config, yet the output from Git talks
about refs/for/refs/meta/config. Copy/paste problem? Pushing
to refs/heads/refs/meta/config will indeed create a new branch
under refs/heads named refs/meta/config.

--
Magnus Bäck
ba...@google.com

Bruce Zu

unread,
Mar 16, 2012, 2:37:41 AM3/16/12
to repo-d...@googlegroups.com
Hi, Magnus
thanks a lot for your help

I just want to know how to update   project.config manually .
I try
-------------------------------
$:~/gerrit-code/gerrit-rebase-compare/local/testp$ git push ssh://bruce.zu@localhost:29418/testp.git HEAD:refs/heads/refs/meta/config
Total 0 (delta 0), reused 0 (delta 0)
remote: Updating references: 100% (1/1)
To ssh://bruce.zu@localhost:29418/testp.git
 * [new branch]      HEAD -> refs/meta/config
$:~/gerrit-code/gerrit-rebase-compare/local/testp$ git push ssh://bruce.zu@localhost:29418/testp.git HEAD:refs/heads/config
Total 0 (delta 0), reused 0 (delta 0)
remote: Updating references: 100% (1/1)
To ssh://bruce.zu@localhost:29418/testp.git
 * [new branch]      HEAD -> config
28850272@cnbjlx6200:~/gerrit-code/gerrit-rebase-compare/local/testp$
-------------------------------
I find on server side the ' refs/meta/config'  has not been updated .








On Thursday, March 15, 2012 7:18:49 PM UTC+8, Magnus Bäck wrote:
On Thursday, March 15, 2012 at 05:42 EDT,
     Bruce Zu <zu.bruc...@gmail.com> wrote:

> Gerrit Code Review 2.2.2
>
> 1> 'push origin config:refs/meta/config  '  get feedback 'error: src
> refspec config does not match any.'

Did you have a ref named "config" in your workspace?

No.  I just reference above  feedback from Johan Björk  Feb 6 , let me copy them here
"

Introduction:
Gerrit 2.2 now supports special submit rules written in prolog. You
can enable it for a project by checking out the refs/meta/config
branch and pushing a file called 'rules.pl'.

 git clone <your project>


 git fetch origin refs/meta/config
 git checkout -b config FETCH_HEAD
 git add rules.pl ; git commit...
 git push origin config:refs/meta/config

"
 especially the tail part of the last line '
git push origin config:refs/meta/config'

> 2> 'push origin HEAD:refs/meta/config'    get feedback ' ! [remote


> rejected] HEAD -> refs/meta/config (can not update the reference as a
> fast forward)
> error: failed to push some refs to ...'

Was your commit based on the tip of refs/meta/config? If not, this error
message is expected.

yes. I update the project.config then   'git commit ' to create a new commit.
only me use this test server and I have not change any thing from WebUI .

 
 

> 3>'push origin config:refs/heads/refs/meta/config'     success however
> new branch created  '* [new branch]      HEAD -> refs/for/refs/meta/config'

sorry for paste error . it should be  
 3>" push origin HEAD:refs/for/refs/meta/config
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 320 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1)
To ssh://bruce.zu@localhost:29418/testp.git

 * [new branch]      HEAD -> refs/for/refs/meta/config"
 

the result is not same as my expectation  to create a new Change.

Um, this isn't consistent. You're saying you pushed to
refs/heads/refs/meta/config, yet the output from Git talks
about refs/for/refs/meta/config. Copy/paste problem? Pushing
to refs/heads/refs/meta/config will indeed create a new branch
under refs/heads named refs/meta/config.

--
Magnus Bäck
ba...@google.com


Mohamed Mansour

unread,
Mar 16, 2012, 2:55:44 AM3/16/12
to Bruce Zu, repo-d...@googlegroups.com
To update your project.config file you should do:

# Checkout your meta/config branch from gerrit
git fetch origin refs/meta/config:refs/remotes/origin/meta/config
git checkout meta/config
 
# Make changes to your project.config file ..
git config --file project.config --add .....
 
# Send them back to gerrit
git commit -a project.config -m "Modified project config file"
git push origin HEAD:refs/config

Kind regards,
Mohamed Mansour



--

Zu, Bruce

unread,
Mar 16, 2012, 5:10:26 AM3/16/12
to Mohamed Mansour, Bruce Zu, repo-d...@googlegroups.com

Hi Mohamed

Thanks for your help

I test on  Gerrit Code Review (2.3-rc0-67-g471e29f)

 

Prepare  permission as

Commands  in local as below

 

 

$ git clone ssh://bruce.zu@localhost:29418/ptest

Cloning into ptest...

remote: Counting objects: 2, done

remote: Finding sources: 100% (2/2)

remote: Total 2 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (2/2), done.

$:~/gerrit-code/google-gerrit/local$ cd ptest/

$ git fetch origin  refs/meta/config:refs/remotes/origin/meta/config

remote: Counting objects: 13, done

remote: Finding sources: 100% (13/13)

remote: Total 13 (delta 0), reused 1 (delta 0)

Unpacking objects: 100% (13/13), done.

From ssh://localhost:29418/ptest

* [new branch]      refs/meta/config -> origin/meta/config

$ git checkout  meta/config

Branch meta/config set up to track remote branch meta/config from origin by rebasing.

Switched to a new branch 'meta/config'

$ git config  --file project.config -e

$ more project.config

[project]

                state = active

                description = "test  config just change here"

[access "refs/heads/*"]

                owner = group Administrators

[access "refs/*"]

                owner = group Administrators

                create = group Administrators

                push = group Administrators

$ git diff

diff --git i/project.config w/project.config

index 8028b0c..568902e 100644

--- i/project.config

+++ w/project.config

@@ -1,6 +1,6 @@

[project]

  state = active

- description = "test  config"

+ description = "test  config just change here"

[access "refs/heads/*"]

  owner = group Administrators

[access "refs/*"]

$ git commit -a  project.config  -m "test updage config manually "

fatal: Paths with -a does not make sense.

$ git commit -a   -m "test updage config manually "

[meta/config f7628d0] test updage config manually

1 files changed, 1 insertions(+), 1 deletions(-)

$ git push origin HEAD:refs/config

Counting objects: 5, done.

Delta compression using up to 4 threads.

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 341 bytes, done.

Total 3 (delta 1), reused 0 (delta 0)

remote: Resolving deltas: 100% (1/1)

remote: Updating changes:done   

To ssh://bruce.zu@localhost:29418/ptest

! [remote rejected] HEAD -> refs/config (Ref Ref[refs/config=4665fe5efed06e27c73c2d7344020a80f887b140] already exists)

error: failed to push some refs to 'ssh://bruce.zu@localhost:29418/ptest'

$

 

 

Bug?

/Bruce

Zu, Bruce

unread,
Mar 16, 2012, 5:26:17 AM3/16/12
to Mohamed Mansour, Bruce Zu, repo-d...@googlegroups.com

Done by little Shift  as below

$ git push origin HEAD:refs/meta/config

Counting objects: 5, done.

Delta compression using up to 4 threads.

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 341 bytes, done.

Total 3 (delta 1), reused 0 (delta 0)

remote: Resolving deltas: 100% (1/1)

remote: Updating changes: refs: 100% (1/1), done   

To ssh://bruce.zu@localhost:29418/ptest

   5747d43..f7628d0  HEAD -> refs/meta/config

$ cd ../../review/git/ptest.git/

$ more refs/meta/config  |xargs  git show

commit f7628d0933cf0c08ec2e58802ef2ed7f623975b0

Author: Bruce Zu <bruc...@sonyericsson.com>

Date:   Fri Mar 16 17:02:45 2012 +0800

 

    test updage config manually

 

diff --git a/project.config b/project.config

index 8028b0c..568902e 100644

--- a/project.config

+++ b/project.config

@@ -1,6 +1,6 @@

[project]

  state = active

- description = "test  config"

+ description = "test  config just change here"

[access "refs/heads/*"]

  owner = group Administrators

[access "refs/*"]

$

 

Anyway it is work on Gerrit Code Review (2.3-rc0-67-g471e29f)  now

I will test  2.2.2 again when I got time.

Thanks a lot !

Mohamed Mansour

unread,
Mar 16, 2012, 10:02:09 AM3/16/12
to Zu, Bruce, Bruce Zu, repo-d...@googlegroups.com
Hey Bruce,

Oh and don't forget the groups file that you have to create that maps uuids and group names. That should be next to the project.config file. Couple of days ago there was a thread that we should how it is structured.


Thanks,
Mohamed Mansour
> <thismessage:/mail/u/0/s/?view=att&th=1361ad5e9fe592a5&attid=0.1&disp=emb&zw&atsh=1>

>
> Commands  in local as below
>
>  
>
>  
>
> $ git clone ssh://bruce.zu@localhost:29418/ptest
>
> Cloning into ptest...
>
> remote: Counting objects: 2, done
>
> remote: Finding sources: 100% (2/2)
>
> remote: Total 2 (delta 0), reused 0 (delta 0)
>
> Receiving objects: 100% (2/2), done.
>
> $:~/gerrit-code/google-gerrit/local$ cd ptest/
>
> $ git fetch origin  refs/meta/config:refs/remotes/origin/meta/config
>
> remote: Counting objects: 13, done
>
> remote: Finding sources: 100% (13/13)
>
> remote: Total 13 (delta 0), reused 1 (delta 0)
>
> Unpacking objects: 100% (13/13), done.
>
> From ssh://localhost:29418/ptest
>
> * [new branch]      refs/meta/config -> origin/meta/config
>
> $ git checkout  meta/config
>
> <
>
Kind regards,
Mohamed Mansour

Zu, Bruce

unread,
Mar 16, 2012, 10:22:59 AM3/16/12
to Mohamed Mansour, Bruce Zu, repo-d...@googlegroups.com

yes. I find there is already a 'gruops' file here together with the project.config after '$ git checkout meta/config'
thanks for your reminder.
/Bruce
________________________________________
From: Mohamed Mansour [m0.inte...@gmail.com]
Sent: Friday, March 16, 2012 10:02 PM
To: Zu, Bruce
Cc: Bruce Zu; repo-d...@googlegroups.com
Subject: Re: "+1" plus "+1" = 2

Hey Bruce,

Oh and don't forget the groups file that you have to create that maps uuids and group names. That should be next to the project.config file. Couple of days ago there was a thread that we should how it is structured.


Thanks,
Mohamed Mansour

On Friday, March 16, 2012, Zu, Bruce <Bruc...@sonymobile.com<mailto:Bruc...@sonymobile.com>> wrote:
> Done by little Shift as below
>
> $ git push origin HEAD:refs/meta/config
>
> Counting objects: 5, done.
>
> Delta compression using up to 4 threads.
>
> Compressing objects: 100% (3/3), done.
>
> Writing objects: 100% (3/3), 341 bytes, done.
>
> Total 3 (delta 1), reused 0 (delta 0)
>
> remote: Resolving deltas: 100% (1/1)
>
> remote: Updating changes: refs: 100% (1/1), done
>
> To ssh://bruce.zu@localhost:29418/ptest
>
> 5747d43..f7628d0 HEAD -> refs/meta/config
>
> $ cd ../../review/git/ptest.git/
>
> $ more refs/meta/config |xargs git show
>
> commit f7628d0933cf0c08ec2e58802ef2ed7f623975b0
>

> Author: Bruce Zu <bruc...@sonyericsson.com<mailto:bruc...@sonyericsson.com>>

> To unsubscribe, email repo-discuss...@googlegroups.com<mailto:repo-discuss%2Bunsu...@googlegroups.com>

Reply all
Reply to author
Forward
0 new messages