[Development] gerrit : pointers to use it cleverly/efficiently?

[Marc Mutz]

On Wednesday 30 March 2016 09:12:13 Sune Vuorela wrote:
> On 2016-03-29, René J.V  Bertin <rjvbertin at gmail.com> wrote:
> > Can someone point me in the right direction, maybe to a tutorial of sorts
> > that outlines how to do several code reviews from a single working copy?
> > 
> > I'm not exactly familiar with using branches; I just tried to create one,
> > apply a patch, commit it and then push to gerrit.
> 
> > That was a bit of a failure; the commit to my local branch was also 
applied to the branch I thought I'd branched off, and the push to gerrit was 
refused:
> Yesterday, I created a review for a bug fix. This is more or less my
> shell history:
> 
> git checkout 3.6 #start from 3.6 branch. qtcreator fix
> git checkout -b readonly-reformat # create a branch, reformatting of qml
> 
> vim/kate/qtcreator/whatever your sources
> make, make test,
> 
> git add ....
> git commit
> git push origin HEAD:refs/for/3.6
> #oops missing change id
> git commit --amend #add changeid
> git push origin HEAD:refs/for/3.6
> #read sanitybot comments
> vim/kate/...
> git commit --amend
> git push origin HEAD:refs/for/3.6
> 
> Add reviewers.
> 
> For next change, go to start.
> When reviews come in, go back to this branch
> 
> git checkout readonly-reformat
> #hack hack hack
> git add
> git commit --amend
> git push origin HEAD:refs/for/3.6

I usually just have one checkout from which I submit, and another one on which 
I develop. This makes it easier for me without an icecream cluster to shoulder 
the compile times. I regularly rebase my work on a local merge of 5.6 and 5.7 
into dev, so merged commits disappear from my local branch, and start a new 
submission branch from then-current gerrit/5.x for the submission checkout. 
When I need to fix a commit, I just

  git checkout sha-from-Gerrit-page

in the submission checkout, usually not bothering to update the corresponding 
change in the development checkout (it will be solved with the next merge from 
upstream) ie. I don't bother keeping branches. I did, but their rebasing is 
just too much work.

So basically, my workflow currently is:

qtbase-work at work$ edit ...
qtbase-work at work$ compile/test (more intensive)
qtbase-work at work$ git add -p
qtbase-work at work$ git commit -m ...
qtbase-work at work$ cd -
qtbase-submit@(no branch)$ git fetch work && git cherry-pick work/work
qtbase-submit@(no branch)$ compile/test (less intensive)
qtbase-submit@(no branch)$ git gpush +thiago +ogoffart +lars ... HEAD:5.6/ubsan
qtbase-submit@(no branch)$ cd -
qtbase-work at work$ edit ...

# oops, review needs update:
qtbase-work at work$ cd -
qtbase-submit@(no branch)$ git checkout sha1-from-Gerrit-page [1]
qtbase-submit@(no branch)$ git fetch gerrit ... && git checkout FETCH_HEAD [1]
qtbase-submit@(no branch)$ edit / compile / test
qtbase-submit@(no branch)$ git push gerrit HEAD:refs/for/5.6

[1] if possible
[2] if git-fsck deleted it locally in the meantime

# periodically (submit)
qtbase-submit@(no branch)$ git fetch gerrit
qtbase-submit@(no branch)$ git checkout gerrit/5.6 # to start anew

# periodically (work):
qtbase-work at work$ git fetch gerrit
qtbase-work at work$ git checkout gerrit/dev
qtbase-work at gerrit/dev$ git merge gerrit/5.7
qtbase-work@(no branch)$ git merge gerrit/5.6
qtbase-work@(no branch)$ gitk & # remember current sha1 :)
qtbase-work@(no branch)$ git rebase --onto HEAD gerrit-dev+merges work [3]
qtbase-work at work$ git tag -d gerrit-dev+merges
qtbase-work at work$ git tag gerrit-dev+mperges sha1-from-open-gitk
qtbase-work at work$ git rebase -i gerrit-dev+merges

[3] resolve conflicts, usually with rebase --skip (when change was upstreamed)
[4] eg. squash oops commits, drop abandoned changes, ...

I haven't checked the multiple-checkouts feature of newer gits, but that would 
make this workflow even simpler, because sha1s would be automatically shared 
between the two checkouts without the need to deal with local remotes and 
their mess of branches.

I only keep this setup for qtbase, because that's where I work almost 
exclusively. For the rest of qt5.git, I just develop and submit from the same 
checkout. 

And I often abuse the submit checkout for development when the development 
checkout is recompiling the world after a change to qglobal.h or similar.

HTH,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts