On Wednesday 30 March 2016 09:12:13 Sune Vuorela wrote: > On 2016-03-29, René J.V Bertin <[email protected]> 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@work$ edit ... qtbase-work@work$ compile/test (more intensive) qtbase-work@work$ git add -p qtbase-work@work$ git commit -m ... qtbase-work@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@work$ edit ... # oops, review needs update: qtbase-work@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@work$ git fetch gerrit qtbase-work@work$ git checkout gerrit/dev qtbase-work@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@work$ git tag -d gerrit-dev+merges qtbase-work@work$ git tag gerrit-dev+mperges sha1-from-open-gitk qtbase-work@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 <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
