Development/gerrit/da

Dette er indgangsiden til koderevisionsværktøjet gerrit.libreoffice.org og hvordan det bruges i LibreOffice.

Gør dig klar til Gerrit
Se Gør dig klar til Gerrit.

Alternativet er at pille løs med en hånddrevet tilgang, som du finder enkeltheder til på Gør dig klar til Gerrit - hånddrevet.

Indsendelse af en patch (lap) til Gerrit
Se Indsend et patch (en lap) til gennemsyn med Gerrit.

I artiklen Indsend et patch (en lap) til gennemsyn med Gerrit finder du en behandling af emner som disse:
 * indsendelse af en ny version
 * indsendelse af patches som kladder

I artiklen Undermoduler finder du en behandling af indsendelse af patches til undermoduler som
 * ordbøger
 * helpcontent2 (til hjælpefiler)
 * oversættelser

Gerrit workflow compared to GitHub/GitLab
The workflow with Gerrit patches is just as simple as GitHub/GitLab pull/merge requests, having only a different approach. With GitHub/GitLab PRs/MRs, you work in a branch and your additional changes will appear as a series of commits. With a Gerrit patch, you keep amending a single commit and your changes will appear as a series of patch sets. In addition to this, for bigger projects it is possible to create a series of patches that depend on each other (Related changes) or even to create remote feature branches.

Gregory Szorc has written an essay about the problems with the GitHub/GitLab patch model. It touches upon Gerrit as well:

"An interesting outlier is Gerrit, which ingests its integration requests via git push. But the way Gerrit's ingestion via git push works is fundamentally different from how pull requests work! With pull requests, you are pushing your local branch to a remote branch and a pull request is built around that remote branch. With Gerrit, your push command is like git push gerrit HEAD:refs/for/master. For the non-gurus, that HEAD:refs/for/master syntax means, push the HEAD commit (effectively the commit corresponding to the working directory) to the refs/for/master ref on the gerrit remote (the SOURCE:DEST syntax specifies a mapping of local revision identifier to remote ref). The wizard behind the curtain here is that Gerrit runs a special Git server that implements non-standard behavior for the refs/for/* refs. When you push to refs/for/master, Gerrit receives your Git push like a normal Git server would. But instead of writing a ref named refs/for/master, it takes the incoming commits and ingests them into a code review request! Gerrit will create Git refs for the pushed commits. But it mainly does that for its internal tracking (Gerrit stores all its data in Git - from Git data to review comments). And if that functionality isn't too magical for you, you can also pass parameters to Gerrit via the ref name! e.g. git push gerrit HEAD refs/for/master%private will create a private review request that requires special permissions to see. (It is debatable whether overloading the ref name for additional functionality is a good user experience for average users. But you can't argue that this isn't a cool hack!)"

Mere om Gerrit

 * se Development/gerrit/PatchReview om hvordan patches gennemses i gerrit
 * Opdel patch efter det blev uploaded til gerrit
 * Development/gerrit/CommonQueries
 * Har du et spørgsmål? Se først gerrit FAQ eller spørg på Developments mail-liste. Du kan også kaste et blik i den officielle gerrit dokumentation.

Mere læsestof

 * EclipseCon 2013: "Deploying Gerrit Code Review"
 * EclipseCon 2013: "Scaling Up JGit"