Wireshark · Wireshark-dev: Re: [Wireshark-dev] Quick start instructions for Gerrit

[Marc Petit-Huguenin <marc@xxxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/19/2013 07:02 AM, Evan Huus wrote:
> Thanks for the information, it is very useful. I am a bit confused though.
> Am I understanding correctly that every open review must be rebased after
> one is landed in master? This is order of n^2 rebases to land n revisions,
> which really doesn't scale. What am I missing?

Theoretically yes, but in real world no.  First, you do not rebase after each
review is merged but periodically, keeping in mind that the longer you wait,
the more conflicts you may have to resolve.  On the other hand rebasing too
often means that if you upload a new patchset each time, this will make things
confusing for the reviewers (who will have to redo their review each time)

Also, the rebase can also be done directly on Gerrit, for example before a
patchset is submitted to the master branch.  If there is a conflict, the
submitter will ask the author of the patch to rebase and resubmit.

So I think that the most efficient model is to do this for each topic branch:

1. Before starting a work session, rebase your branch. Then do the
modifications requested by the reviewers, amend your patchset and push it.

2. If the submitter asked you to rebase, rebase, resolve the conflicts and
push the patchset.

This minimize the number of patchsets submitted for review, at the expense of
slowing down from time to time the patchset cycle when a last rebase/resolve
conflict is needed before the merge in master.

Personally I like to start my day of work with a pull and a round of rebase in
all my topic branches, as I keep forgetting to rebase my branches when I had
to fix something following a review.

> 
> Thanks, Evan
> 
> On 2013-09-18, at 8:52 PM, Marc Petit-Huguenin <marc@xxxxxxxxxxxxxxxxxx> 
> wrote:
> 
> Thess quick start instructions assume that you know about git, that you 
> already have an ssh key pair configured and that ssh and git are installed 
> on your computer.  Note that the email configured in git must match the 
> email that you used in the Gerrit configuration.
> 
> First step is to clone the Wireshark repository, which need to be done only
>  one time:
> 
> - Start by creating a new account in Gerrit by going to the 
> http://test.code.wireshark.org/review/ page, and clicking of the Register 
> link, on the top right.
> 
> - Here the simplest is to use an existing Google or Yahoo ID.  Just follow 
> the instructions until you are back on the test.code.wireshark.org site.
> 
> - On the page, choose a username and save it.  Copy the content of your ssh
>  public key (~/.ssh/id_rsa.pub) and add it, then click continue.  You are 
> done for now with the web interface.
> 
> - Go to your command line and enter the following command (replacing 
> <username> by the user name you entered in the web page):
> 
> git clone 
> ssh://<username>@test.code.wireshark.org:29418/wireshark-review-sandbox
> 
> - After it is done (it will take a minute of so), install the change-id
> hook with the following commands:
> 
> cd wireshark-review-sandbox scp -p -P 29418 
> <username>@test.code.wireshark.org:hooks/commit-msg .git/hooks/
> 
> - Finally install a shortcut to push patchsets:
> 
> git config --add remote.origin.push HEAD:refs/for/master
> 
> 
> After this, you can prepare your first patchset.  One of the essential
> rule is that you *never*, *ever* work in the master branch.  This branch
> must be considered read-only.  So to create a patchset, you need first to
> create a topic branch.  I personally always name a topic branch so it ends
> with the name of the branch onto which the patchset will be merged, so in
> this case, -master:
> 
> git checkout -b first-patchset-master
> 
> This will create a new branch (from the tip of the master branch) and
> switch to it (you can list your branches with "git branch")
> 
> Now you can do all your modifications.  When you are done, you need to 
> commit them.  The simplest is this command:
> 
> git commit -a
> 
> Note that git will ask you for a commit message, which is as important as 
> the modified code itself.  The usage if to have a title of no more than 50
>  characters, an empty line, then an explanation on the commit itself.
> 
> After the modifications are committed you can review the commit with "git 
> log -p".  Note that a field name "Change-ID" was automatically added.
> This is the magic that will glue multiple revisions of the same patchset,
> do not modify it.  If everything looks fine, you can push it with the
> following command:
> 
> git push
> 
> And that's it, congratulations, your first patchset is ready for review,
> and you can see it on the website, by clicking on My|Changes.
> 
> Obviously some patchsets will probably be merged in the master branch
> before your patchset is reviewed and merged, so you will need to rebase it.
> First to need to switch back to the master branch and to pull all the new 
> modifications:
> 
> git checkout master git pull
> 
> If you followed the rule above (never work on the master branch), there 
> should not be any conflicts when running the "git pull" command.  The next 
> step is to rebase your patchset:
> 
> git rebase master first-patchset-master
> 
> There may be conflicts at this time.  Resolve them, do a "git add" of the 
> modified files and then finish the rebase with the following command with 
> the following command:
> 
> git rebase --continue
> 
> (you may have to do that multiple times)
> 
> It may be a good time to do the modifications that were requested by your 
> reviewers:  apply then then amend the existing commit (do not add a new 
> commit, you want a clean history, not a catalog of your mistakes):
> 
> git commit --amend -a
> 
> Then push again your patchset:
> 
> git push
> 
> The new patchset will appear on the web page in parallel to the previous 
> patchset, where it can be reviewed again and eventually merged into
> master.
> 
> After your patchset is merged into master, do a pull and a rebase again of
>  your (now useless) branch.  If everything went well, you should be able to
>  safely delete the topic branch with this command (the branch will not be 
> deleted if it was not completely merged):
> 
> git checkout master git branch -d first-patchset-master
> 
> Enjoy!
> 


- -- 
Marc Petit-Huguenin
Email: marc@xxxxxxxxxxxxxxxxxx
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCAAGBQJSOw0xAAoJECnERZXWan7EcTQP/05SRm2bsuSEdoAhSwK7Y0bY
OI6IRxEj/GbBFCnr4mCJnC5EgY/gJ5Iqp+IbQT42fHHlhZdu9+9DjXe/N4bEntWl
lN6f7wrSYwuevNo2mpw+6Z9bfaCobTod34TaHhPHjiKYSg50zzExaQGgAaWzIiJZ
hDT+tjc3Dug4kZV7CmcOgOSG2JP8/cBXxgFsC+o501NRDJr8ylV6hvIMLseqlWR8
yOSNaR8atZ2WOh6WW05+/jrFfSFmPQXaPaqBiilkAgTFmzoefNzmEWCaST5eMGyC
CKjS819hT3C5NXNOkCcq5aeH+jV9Xl5m8L33GoEryXas4EuscPyMAffXVTun8Nu7
9vj+eMauFo75Yi5T5KfvmgtUV6WL1qmYT2FvUONGdvVYsrTQhzAyt4QQdEtzLOL8
qpGuoKmqmP4SCox47GBpsNDUlPA7IHAk4meHjumcLmMRB4ux74qZ0xpCbPLY3NTj
PsJwaDUUv17vGDoLl0lYefh0kHYwpBcgF2N9N6VmLHU26+Oi2hk2g8XwdOB08lt7
HdYFM7WZ3AJ/R7VcUUwRgJtWyn3TwxCMzOEcW/J9L1mwglcIEIVCm5h9ljSi/Nd0
C+WTfcdLgf0iB0vT14F+wqs67FPxi5dJnbZW/sADST5ZVuSARmEJfYJt6j0JKPSt
yDxez4zn2FaebsdlqZ2S
=8FFQ
-----END PGP SIGNATURE-----