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