Gerrit » History » Version 110
fixeria, 12/21/2018 06:32 PM
1 | 110 | fixeria | h1. Contributing using Gerrit |
---|---|---|---|
2 | 99 | fixeria | |
3 | 1 | zecke | {{>toc}} |
4 | 11 | laforge | |
5 | 106 | stsp | At [[OpenBSC:OsmoDevCon2016]] we discussed problems with our past contribution / patch submission process using mails on the mailing list as well as patchwork. The result was that we wanted to give Gerrit a try for some time and see if it helps us to have a better process |
6 | 1 | zecke | |
7 | 10 | laforge | Gerrit is a review tool that integrates nicely with git and ssh. You can find general information about Gerrit at https://www.gerritcodereview.com/ |
8 | 1 | zecke | |
9 | 10 | laforge | The advantages of Gerrit are: |
10 | * patch submission status is automatically tracked, also with several revisions for a patch set. |
||
11 | * patches are build-tested (and possibly even further tested) by jenkins before they are applied |
||
12 | 108 | stsp | * patch submissions not via git send-email but direcly from git |
13 | 10 | laforge | |
14 | h2. Osmocom Subprojects using Gerrit |
||
15 | |||
16 | 73 | laforge | The majority of Osmocom sub-projects have chosen to use Gerrit for patch review. In order to check if a given program uses Gerrit, please check the auto-generated list at https://gerrit.osmocom.org/#/admin/projects/ |
17 | 1 | zecke | |
18 | 75 | laforge | If the project is listed there, then it uses Gerrit. If the project is not listed there, please send patches by e-mail to the respective project [[Mailing_Lists]] instead. |
19 | 30 | neels | |
20 | 1 | zecke | h2. Configuring Gerrit/Account |
21 | |||
22 | 109 | stsp | You will need to sign up at https://gerrit.osmocom.org/login/. If you have an Osmocom Redmine account you can use https://osmocom.org/openid as OpenID provider. |
23 | 1 | zecke | |
24 | 109 | stsp | * first sign in on https://osmocom.org. Do this before logging into gerrit (the redmine login process loses the gerrit login data and you'd have to do the same thing twice if not logged in on osmocom.org already). |
25 | 55 | neels | * go to https://gerrit.osmocom.org and click the "Sign in" link. |
26 | 68 | neels | * click the "Sign in with Osmocom":https://gerrit.osmocom.org/login/%23%2Fq%2Fstatus%3Aopen?id=https://osmocom.org/openid link (can be bookmarked). -- This is the same as entering https://osmocom.org/openid as OpenID provider and hitting the "Sign in" button. |
27 | 61 | neels | |
28 | 109 | stsp | *careful:* enter 'https' to ensure that your openid credentials are passed on encrypted. |
29 | 68 | neels | *pitfall:* if you're logged in on 'projects.osmocom.org' (including the 'projects.' part), you should also use the openid provider: https://projects.osmocom.org/openid; the 'projects.' part may be omitted, what's important is that redmine login and OpenID URLs match. Also, decide for one of those URLs once, because when picking a different OpenID URL next time, you will create a new user instead of logging in as yourself. |
30 | 61 | neels | *note:* gerrit will create a distinct user for each openid URL you pass. If you logged in successfully but your user seems to have lost permissions, you may have created an evil twin user: contact us on the mailing list so we can fix it in the user database. |
31 | 54 | neels | |
32 | If you have no Osmocom redmine account, you can simply create one online at the "Register" link in the upper right corner. |
||
33 | 10 | laforge | Even without an existing or new redmine account, you should also be able to use any other OpenID provider to authenticate against gerrit (untested). |
34 | |||
35 | After the initial sign-up you will need to: |
||
36 | 1 | zecke | |
37 | 109 | stsp | * Pick a username (cannot be changed) |
38 | 1 | zecke | * Add your public ssh key(s) |
39 | * Add email addresses you intend to use as author/comitter |
||
40 | 30 | neels | |
41 | If you would like to push private branches to the Gerrit repository, you also need to be added to the "known users" group. |
||
42 | Please send a short requesting email to openbsc@lists.osmocom.org. |
||
43 | 1 | zecke | |
44 | h2. Setting up Gerrit for commits and pushing |
||
45 | |||
46 | 33 | neels | *Note:* it is easiest to work with gerrit when gerrit is the only remote in your git clone. |
47 | When you clone from git.osmocom.org and add the gerrit remote, git will have two remotes, |
||
48 | 36 | neels | so when you first checkout a branch you have to supply the remote explicitly (cumbersome). |
49 | 34 | neels | The gerrit repositories and git.osmocom.org are constantly synced, so it is sufficient |
50 | to clone from gerrit only. |
||
51 | 33 | neels | |
52 | h3. Simplest: new clone |
||
53 | |||
54 | 35 | neels | * Create a new clone from gerrit |
55 | * Fetch the commit hook that adds Change-Id to each commit to uniquely identify a commit |
||
56 | 42 | neels | |
57 | 33 | neels | <pre> |
58 | git clone ssh://$USERNAME@gerrit.osmocom.org:29418/$PROJECT.git |
||
59 | scp -P 29418 $USERNAME@gerrit.osmocom.org:hooks/commit-msg $PROJECT/.git/hooks/ |
||
60 | </pre> |
||
61 | |||
62 | h3. SSH config |
||
63 | |||
64 | In '~/.ssh/config', add these lines: |
||
65 | <pre> |
||
66 | 52 | neels | Host go |
67 | 33 | neels | Hostname gerrit.osmocom.org |
68 | Port 29418 |
||
69 | User $USERNAME |
||
70 | </pre> |
||
71 | 52 | neels | ('go' means gerrit.osmocom, replace with your favorite shortcut name, |
72 | 33 | neels | replace '$USERNAME' with your user name as used on the gerrit website) |
73 | |||
74 | Then you can shorten above commands to |
||
75 | 1 | zecke | <pre> |
76 | 52 | neels | git clone ssh://go/$PROJECT.git |
77 | 51 | neels | cd $PROJECT |
78 | scp go:hooks/commit-msg .git/hooks/ |
||
79 | 33 | neels | </pre> |
80 | |||
81 | 1 | zecke | h3. Committer must match |
82 | 46 | neels | |
83 | 1 | zecke | Your email address on gerrit and the email address git places in your |
84 | 46 | neels | commits must match, or you will get rejected with an error message like |
85 | 108 | stsp | "invalid committer". You can add email addresses on the gerrit web UI. |
86 | 47 | neels | |
87 | 1 | zecke | h3. Add gerrit to an existing clone |
88 | |||
89 | * Add the remote to be able to fetch and push to gerrit |
||
90 | 46 | neels | * Fetch the commit hook that adds Change-Id to each commit to uniquely identify a commit |
91 | 1 | zecke | |
92 | 46 | neels | <pre> |
93 | 1 | zecke | USERNAME=gerrit_user_name |
94 | PROJECT=$(basename $PWD) |
||
95 | git remote add gerrit ssh://$USERNAME@gerrit.osmocom.org:29418/$PROJECT.git |
||
96 | scp -P 29418 $USERNAME@gerrit.osmocom.org:hooks/commit-msg .git/hooks/ |
||
97 | </pre> |
||
98 | |||
99 | h2. Push for review |
||
100 | |||
101 | Prerequisites: |
||
102 | |||
103 | * your user on gerrit has an SSH public key |
||
104 | * your patch is committed in your local clone |
||
105 | * the commit log message has a Change-Id (see 'commit-msg' hook above, and 'Tips and Tricks' below to add a Change-Id to a commit that lacks one.) |
||
106 | |||
107 | <pre> |
||
108 | git push $REMOTE $GITHASH:refs/for/$BRANCH/$TOPIC |
||
109 | </pre> |
||
110 | |||
111 | $REMOTE: from above instructions, that's either 'origin' (cloned from gerrit) or 'gerrit' (if you added a second remote). |
||
112 | $GITHASH: the committed patch to push, typically you're on your branch and simply push 'HEAD'. |
||
113 | $BRANCH: you will typically intend a patch to go to 'master'. |
||
114 | $TOPIC: an optional name you may choose. |
||
115 | |||
116 | 109 | stsp | For example, check out the revision or branch that you want to submit for review, |
117 | 1 | zecke | i.e. the one where your patch or several patches are committed on top of the current master, then: |
118 | |||
119 | If you cloned directly from gerrit: |
||
120 | |||
121 | <pre> |
||
122 | git push origin HEAD:refs/for/master |
||
123 | </pre> |
||
124 | |||
125 | If you added 'gerrit' as a second remote to an existing clone: |
||
126 | |||
127 | <pre> |
||
128 | git push gerrit HEAD:refs/for/master |
||
129 | </pre> |
||
130 | |||
131 | You can optionally add a topic name with |
||
132 | |||
133 | <pre> |
||
134 | git push origin HEAD:refs/for/master/my_topic |
||
135 | </pre> |
||
136 | |||
137 | 102 | stsp | h2. Voting Rules for merging a patch to master |
138 | 7 | neels | |
139 | 103 | stsp | Please follow these voting rules: |
140 | 44 | neels | |
141 | 102 | stsp | h3. Code Review ("CR") |
142 | 77 | neels | |
143 | 102 | stsp | * Please review patches by others. |
144 | * Do not vote for your own patches (exceptions below). |
||
145 | * Before merging, each patch should receive at least two reviews that approve merging. |
||
146 | 77 | neels | |
147 | 102 | stsp | When voting, please follow this social contract: |
148 | 77 | neels | |
149 | 102 | stsp | * When you approve, vote CR +1. |
150 | * If there already is someone else's CR +1, you may also choose to vote CR +2. |
||
151 | * If the patch owner sees two or more CR +1, the patch owner may apply to self a CR +2. |
||
152 | * Once there is at least one CR +2 and one CR +1 vote, a patch may be merged ("Submit" button), except: |
||
153 | ** If there are two -1 votes, you should not merge, instead clarify the reason and try to fix it. |
||
154 | ** If there is a single -1 vote, you may still merge the patch, if you are sure that the opinion of the -1 vote does not carry. |
||
155 | * Give the benefit of the doubt to the -1 vote, do not lightheartedly overrule. |
||
156 | * If there is a CR -2 vote, the patch will likely never pass review, it marks a fundamental flaw. |
||
157 | * Merging a patch ("Submit" button) may be done by a reviewer or by the patch owner, |
||
158 | But if there is any negative vote, rather leave merging up to the patch owner. |
||
159 | * If you remove a +1 vote, try to make sure that there are no other CR +2 votes left alone |
||
160 | (to prevent accidental "Submit including parents"). If needed, ping other reviewer / admin on IRC. |
||
161 | But try to vote +1 only when you're sure, hence this situation should be rare. |
||
162 | * To prevent merging of your own patch before some issue is resolved, consider marking it Work In Progress. |
||
163 | |||
164 | 104 | stsp | h3. Exceptions for Trivial / Urgent Patches |
165 | 102 | stsp | |
166 | A patch may receive a direct +2 when: |
||
167 | |||
168 | * it is very trivial, like a typo fix in a comment or log string, so that it is not worth wasting review time on. |
||
169 | * it reverts an earlier change that broke the master builds. |
||
170 | |||
171 | In these cases, the patch submitter may decide to +2 to self, after careful consideration. This should be rare. |
||
172 | |||
173 | h3. Verification ("V") |
||
174 | |||
175 | * For most projects, jenkins takes care of voting V +1 automatically. |
||
176 | * If you have actually tried out a patch and verified that it works, you may vote V +1. |
||
177 | * A patch owner may vote V +1 to self in a project that has no Jenkins verification job. |
||
178 | |||
179 | h3. Rationale |
||
180 | |||
181 | Gerrit allows merging a patch as soon as a CR +2 vote and a V +1 vote are in. |
||
182 | For quite some time, we had CR +2 permissions for only very few gatekeeper reviewers. |
||
183 | The result was that non-gatekeepers' votes seemed to not matter. |
||
184 | |||
185 | To encourage more peer review that actually has an effect, we would like to sum up +1 votes. |
||
186 | We have tried to apply a summing of votes in Gerrit with automatic enforcing |
||
187 | ( https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#_example_13_1_1_2_code_review ) |
||
188 | but this had numerous quirks, particularly the issues summary shows wildly mismatching voting status. |
||
189 | |||
190 | The solution is to agree on a social contract: everyone gets +2 permissions, |
||
191 | but you shall only use it when it makes sense. Thanks! |
||
192 | |||
193 | 1 | zecke | |
194 | 84 | neels | h2. Manage private branches |
195 | 1 | zecke | |
196 | 84 | neels | Use a sub-directory with your name to group your own branches, please. |
197 | 1 | zecke | *Note* that you must be a member of the "known users" group, see above. |
198 | |||
199 | 85 | neels | To share / backup local branches to git.osmocom.org, without starting a code review process on gerrit.osmocom.org, just push them as usual to gerrit. |
200 | 84 | neels | |
201 | * Note that the git repository must be cloned from the gerrit SSH URL -- all pushing goes to gerrit ("pushurl" as described below also works). |
||
202 | * All private branches are automatically synced to git.osmocom.org in a matter of minutes. |
||
203 | 86 | neels | * Private branches do not kick off patch sets for review, they are just branches. To kick off review for all patches on your branch, you'd use a 'refs/for/master' URL, as shown in the example below. |
204 | 84 | neels | |
205 | The typical transcript for "Fred" developing feature "Kazoo" looks like this: |
||
206 | |||
207 | 1 | zecke | <pre> |
208 | 84 | neels | # Set up ~/.ssh/config so that 'go' points at gerrit.osmocom.org |
209 | git clone ssh://go/libosmocore |
||
210 | |||
211 | cd libosmocore |
||
212 | git checkout -b fred/kazoo # create local branch |
||
213 | |||
214 | $EDITOR |
||
215 | git add kazoo.c |
||
216 | git commit -m "implement kazoo" |
||
217 | |||
218 | # just invoke 'git push' and git tells you how to create the branch once-off: |
||
219 | 1 | zecke | git push |
220 | 84 | neels | |fatal: The current branch asdf has no upstream branch. |
221 | |To push the current branch and set the remote as upstream, use |
||
222 | | |
||
223 | | git push --set-upstream origin fred/kazoo |
||
224 | 1 | zecke | |
225 | 84 | neels | git push --set-upstream origin fred/kazoo |
226 | # Now the branch exists on gerrit, very soon will also exist on git.osmocom.org |
||
227 | |||
228 | # Further tweaks |
||
229 | $EDITOR |
||
230 | git add kazoo.h |
||
231 | git commit --amend |
||
232 | |||
233 | # You are free to force-push private branches |
||
234 | git push -f |
||
235 | |||
236 | # origin/master has changed? Rebase onto the latest. |
||
237 | git fetch |
||
238 | git rebase -i origin/master |
||
239 | # resolve conflicts... |
||
240 | git push -f |
||
241 | |||
242 | # Feature is ready |
||
243 | git push origin HEAD:refs/for/master/kazoo |
||
244 | 39 | neels | </pre> |
245 | 7 | neels | |
246 | 48 | ahuemer | h2. List changesets in gerrit |
247 | 2 | zecke | |
248 | 12 | msuraev | <pre> |
249 | 17 | neels | git ls-remote gerrit changes/* |
250 | 1 | zecke | </pre> |
251 | 80 | neels | |
252 | h1. Tips and Tricks |
||
253 | |||
254 | h2. A commit lacks a Change-Id |
||
255 | |||
256 | once you added the commit hook as above, just re-edit the commit log message, e.g. with |
||
257 | |||
258 | <pre> |
||
259 | git commit --amend |
||
260 | </pre> |
||
261 | |||
262 | or by |
||
263 | |||
264 | <pre> |
||
265 | git rebase -i |
||
266 | </pre> |
||
267 | |||
268 | and in the upcoming editor replacing 'pick' with 'r' in front of the commit to edit. |
||
269 | 74 | neels | |
270 | No need to change the commit log if you don't want to, just exit the editor and the commit hook will add a Change-Id. |
||
271 | 79 | neels | |
272 | 87 | msuraev | h2. Ignore WIP patches |
273 | |||
274 | Using following operators in "search" field of web UI allows to ignore Work-in-progress changes: |
||
275 | <pre> |
||
276 | status:open AND -is:wip |
||
277 | </pre> |
||
278 | |||
279 | 79 | neels | h2. Fetch fast from git.osmocom.org, push to gerrit |
280 | |||
281 | 1 | zecke | Gerrit has moved to a faster host, so this should no longer be necessary. Anyway... |
282 | 74 | neels | |
283 | 109 | stsp | Adding a second remote forces you to explicitly pass the remote on the command line ("origin"). |
284 | It is possible to have only one remote for convenience, with different push and pull URLs: |
||
285 | 79 | neels | |
286 | 74 | neels | <pre> |
287 | 1 | zecke | git remote set-url origin git://git.osmocom.org/$PROJECT |
288 | 74 | neels | git remote set-url --push origin ssh://$USERNAME@gerrit.osmocom.org:29418/$PROJECT |
289 | </pre> |
||
290 | 79 | neels | |
291 | 74 | neels | With above .ssh config you can also use the shorter ssh:// URL: |
292 | <pre> |
||
293 | 79 | neels | git remote set-url --push origin ssh://go/$PROJECT |
294 | 74 | neels | </pre> |
295 | |||
296 | The resulting .git/config in libosmocore would look something like: |
||
297 | <pre> |
||
298 | [remote "origin"] |
||
299 | url = git://git.osmocom.org/libosmocore |
||
300 | pushurl = ssh://go/libosmocore |
||
301 | fetch = +refs/heads/*:refs/remotes/origin/* |
||
302 | </pre> |
||
303 | 17 | neels | |
304 | Now you're fetching from git.osmocom.org, which is lightning fast, while pushing patches will still go to gerrit as usual. |
||
305 | |||
306 | 45 | neels | h2. Throw-away branch |
307 | 13 | neels | |
308 | 56 | neels | If you need to adjust and re-submit patches, it may be handy to create a throw-away branch ("R D" in magit-gerrit in emacs for example), |
309 | make your changes/amendments and then send patch(es) back to gerrit while removing temporary branch automatically with "git review -f". |
||
310 | |||
311 | h2. Fetch a patch from gerrit |
||
312 | |||
313 | This script (I called it @P@) makes fetching a patch set from gerrit a breeze: |
||
314 | <pre> |
||
315 | #!/bin/sh |
||
316 | # fetch gerrit patch into new branch named like the patch number. |
||
317 | # |
||
318 | # Usage: go to a git clone and pass a patch number: |
||
319 | # |
||
320 | # cd openbsc |
||
321 | # P 973 |
||
322 | # or |
||
323 | # P 973/2 |
||
324 | # |
||
325 | # Will create new local branches '973_4' (if 4 is the latest patch set) |
||
326 | # or '973_2', respectively. |
||
327 | |||
328 | patch="$1" |
||
329 | |||
330 | if [ -z "$patch" ]; then |
||
331 | echo "Usage: P 1234[/5]" |
||
332 | exit 1 |
||
333 | fi |
||
334 | |||
335 | if [ -z "$(echo "$patch" | grep '/')" ]; then |
||
336 | patch="/$patch/" |
||
337 | fi |
||
338 | |||
339 | if [ -z "$(echo "$patch" | grep '^/')" ]; then |
||
340 | patch="/$patch" |
||
341 | fi |
||
342 | |||
343 | last_set="$(git ls-remote origin "changes/*" | grep "$patch" | sed 's#.*/\([^/]*\)$#\1 &#' | sort -n | tail -n 1)" |
||
344 | if [ -z "$last_set" ]; then |
||
345 | echo "Not found: $patch" |
||
346 | exit 1 |
||
347 | fi |
||
348 | |||
349 | change_name="$(echo "$last_set" | sed 's/.*\(refs.*\)/\1/')" |
||
350 | branch_name="$(echo "$change_name" | sed 's#refs/changes/../\([0-9]*\)/\([0-9]*\)#\1_\2#')" |
||
351 | |||
352 | set -x |
||
353 | git fetch origin "$change_name" |
||
354 | 25 | neels | git co -b "$branch_name" FETCH_HEAD |
355 | 13 | neels | </pre> |
356 | 1 | zecke | |
357 | 58 | neels | h2. Re-submit a Branch with Amended Commits |
358 | |||
359 | 22 | neels | On a feature branch, one typically has numerous commits that depend on their preceding commits. |
360 | 58 | neels | Often, some of the branch commits need to be amended for fixes. You can re-submit changes to |
361 | patches on your branch by pushing in the same way that you first submitted the branch. |
||
362 | |||
363 | 29 | neels | Note: if you modify the Change-Ids in the commit logs, your push would open entirely new |
364 | 58 | neels | review entries and you would have to abandon your previous submission. Comments on the first |
365 | submission are "lost" and you cannot diff between patch sets. |
||
366 | 29 | neels | |
367 | 26 | neels | |
368 | 1 | zecke | h2. Re-submit Previously Abandoned Changes |
369 | |||
370 | You have to edit the Change-Ids, on a branch that would be every single commit log message. |
||
371 | |||
372 | <pre> |
||
373 | cd openbsc |
||
374 | git co my-branch |
||
375 | git rebase -i master |
||
376 | # replace all 'pick' with 'r' (or 'reword'), exit your editor |
||
377 | # git presents each commit log message for editing |
||
378 | </pre> |
||
379 | |||
380 | 78 | neels | h2. 502 Bad Gateway |
381 | |||
382 | When getting a "Bad Gateway" error message upon trying to login on gerrit, you probably just need to restart your web browser. The reason is not clear. |
||
383 | |||
384 | |||
385 | h2. Commit hook: Always put Change-Id at the bottom of the log message |
||
386 | |||
387 | The commit-msg hook places a Change-Id tag in the footer, often above other tags like 'Depends:' or 'Related:'. Since the Change-Id is an implementation detail for Gerrit, I personally prefer it always placed right at the bottom. This simple edit changes the commit-msg hook to add Change-Id at the bottom unconditionally: |
||
388 | |||
389 | <pre> |
||
390 | cd $PROJECT |
||
391 | sed -i 's/if (unprinted /if (0 \&\& unprinted /' .git/hooks/commit-msg |
||
392 | </pre> |
||
393 | |||
394 | The goal is to disable the condition in line 163 with an 'if (0...': |
||
395 | |||
396 | <pre> |
||
397 | if (0 && unprinted && match(tolower(footer[line]), changeIdAfter) != 1) { |
||
398 | unprinted = 0 |
||
399 | print "Change-Id: I'"$id"'" |
||
400 | } |
||
401 | 60 | neels | </pre> |
402 | 16 | neels | |
403 | 13 | neels | Then the Change-Id will be placed by line 170 instead. |
404 | 16 | neels | |
405 | h1. Reasons for Particular Configuration |
||
406 | |||
407 | 13 | neels | h2. Rebase if necessary |
408 | |||
409 | There are different merge strategies that Gerrit performs to accept patches. |
||
410 | Each project can be configured to a specific merge strategy, but unfortunately you can't |
||
411 | decide on a strategy per patch submission. |
||
412 | |||
413 | It seems that the "Merge if Necessary" strategy is best supported, but it creates non-linear |
||
414 | history with numerous merge commits that are usually not at all necessary. |
||
415 | |||
416 | Instead, the "Cherry Pick" strategy puts each patch onto current master's HEAD to create |
||
417 | 1 | zecke | linear history. However, this will cause merge failures as soon as one patch depends on |
418 | 13 | neels | another submitted patch, as typical for a feature branch submission. |
419 | |||
420 | 1 | zecke | So we prefer the "Rebase if Necessary" strategy, which always tries to apply your patches to |
421 | 13 | neels | the current master HEAD, in sequence with the previous patches on the same branch. |
422 | |||
423 | h2. Private Branches: Create a new change for every commit... |
||
424 | 16 | neels | |
425 | 13 | neels | Say you have an extensive feature in development, and you want to keep it on the |
426 | upstream git repository to a) keep it safe and b) collaborate with other devs on it. |
||
427 | So, of course, you have regularly pushed to refs/heads/yoyodyne/feature. |
||
428 | |||
429 | Since you have the gerrit commit hook installed, your feature branch already has |
||
430 | Change-Id tags in all commit log messages. |
||
431 | |||
432 | Now your feature is complete and you would like to submit it to master. |
||
433 | 16 | neels | Alas, Gerrit refuses to accept your patch submission for master, because it |
434 | knows the Change-Ids are also on a different branch. |
||
435 | |||
436 | Gerrit by default enforces that a Change-Id must be unique across all branches, |
||
437 | so that each submission for review is separate for each branch. Instead, we |
||
438 | 13 | neels | want to handle Change-Ids per-branch, so that you can have the same change |
439 | 16 | neels | submitted to different branches, as separate patch submissions, without having |
440 | to cosmetically adjust the Change-Id. |
||
441 | 13 | neels | |
442 | 20 | neels | Solution: set the option |
443 | 14 | neels | _Create a new change for every commit not in the target branch_ to _TRUE_ |
444 | |||
445 | h2. Allow content merges |
||
446 | |||
447 | By default, gerrit compares patches only by the files' paths. If two paths are the same, |
||
448 | it immediately shows them as conflicts (path conflicts). |
||
449 | |||
450 | 23 | neels | In software development, a conflict usually means an actual content conflict, so if the |
451 | 14 | neels | edits are in two entirely separate places in the file, we don't consider this a conflict. |
452 | |||
453 | 32 | neels | By setting _Allow content merges_ to _TRUE_ in the git project config, we tell Gerrit to |
454 | perform text merges of the submitted patches and only complain about actual content |
||
455 | conflicts, in the usual software engineering sense. |
||
456 | 72 | laforge | |
457 | h1. Admin |
||
458 | |||
459 | h2. Adding a new repository |
||
460 | |||
461 | * create the repository in the Gerrit Ui, inherit from "All-Projects" |
||
462 | * create an empty git repository using gitosis on git.osmcoom.org |
||
463 | 88 | osmith | * configure a jenkins build testing job for this project (see gerrit-verifications.yml in osmo-ci.git/jobs) |
464 | 92 | osmith | |
465 | 72 | laforge | |
466 | 32 | neels | git replication to gerrit.osmocom.org is enabled automatically, nothing to be done here. In case of doubt, try |
467 | @ssh -p 29418 gerrit.osmocom.org replication start --all --wait@ |
||
468 | |||
469 | h2. Adding users to groups |
||
470 | |||
471 | Normally, the gerrit UI auto-completes a user name in the edit field. It has happened |
||
472 | though that an existing user is not auto-completed, as if it didn't exist. In that case, |
||
473 | find out the user ID (seven digit number like 1000123) and just enter that. |
||
474 | |||
475 | The user ID can be found on the user's "Settings" page, or in the database (s.b.). |
||
476 | |||
477 | h2. Querying the database directly |
||
478 | |||
479 | If your user has permission to access the database, you can place SQL queries using the |
||
480 | 71 | neels | 'gerrit gsql' commands over ssh: |
481 | |||
482 | 1 | zecke | <pre> |
483 | 53 | neels | ssh go "gerrit gsql -c \"show tables\"" |
484 | ssh go "gerrit gsql -c \"select full_name,account_id from accounts\"" |
||
485 | 1 | zecke | </pre> |
486 | |||
487 | 71 | neels | (see ~/.ssh/config above for the 'go' shortcut) |
488 | |||
489 | 62 | neels | This seems to be the MySQL dialect. |
490 | |||
491 | The "...\"...\"" quoting allows including single-quotes in the SQL statements. |
||
492 | |||
493 | h2. Fix evil twin users |
||
494 | |||
495 | 64 | neels | If differing openid URLs have lead to evil twin users shadowing the same email address just without the permissions, you can fix it like this: |
496 | 62 | neels | |
497 | <pre> |
||
498 | ssh go "gerrit gsql -c \"select * from account_external_ids where email_address like '%foo%'\"" |
||
499 | # ACCOUNT_ID | EMAIL_ADDRESS | PASSWORD | EXTERNAL_ID |
||
500 | # -----------+-----------------+----------+---------------------------------- |
||
501 | 64 | neels | # 100004 | foo@example.com | NULL | https://osmocom.org/openid/user/777 |
502 | 62 | neels | # 100021 | foo@example.com | NULL | https://projects.osmocom.org/openid/user/777 |
503 | 64 | neels | |
504 | 62 | neels | ssh go "gerrit gsql -c \"update account_external_ids set account_id = 100004 where email_address like '%foo%'\"" |
505 | |||
506 | ssh go "gerrit gsql -c \"select * from account_external_ids where email_address like '%foo%'\"" |
||
507 | # ACCOUNT_ID | EMAIL_ADDRESS | PASSWORD | EXTERNAL_ID |
||
508 | # -----------+-----------------+----------+---------------------------------- |
||
509 | 1 | zecke | # 100004 | foo@example.com | NULL | https://osmocom.org/openid/user/777 |
510 | # 100004 | foo@example.com | NULL | https://projects.osmocom.org/openid/user/777 |
||
511 | </pre> |