[Insight-developers] Gerrit / git primer

[Bill Lorensen]

Dan,

Under reviewing can you describe how, as a reviewer, I should pull
changes locally? The e-mail that is sent has a bogus url.  (Brad King
is working to fix this).
The steps might me something like this:
As a reviewer, you may want to pull the changes locally, build, run
and test the changes.
1) Create a new branch
    git branch MyReview
2) Checkout the branch
    git checkout MyReview
3) Pull the code to be reviewed.
    Here, you cannot rely on the url listed in the e-mail. For example,
git pull ssh://review.source.kitware.com:29418/ITK refs/changes/76/76/1
will fail. INstead, I go to the download section of the review page,
choose Anonymous http, and copy the url to the clipboard, then paste
into my shell.
4) Run cmake, make and then ctest

\Bill

On Fri, Sep 17, 2010 at 10:15 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Dan and Matt,
> Great work Dan, lots of details.
> We also need to add compile and TEST before each commit! This is very
> important.
> 1) I would also recommend that the contributers turn on the following option
> when committing commits for gerrit:
>  git config hooks.GerritId true
> This would automatically add the Chagne-Id, which will greatly simplify the
> submission of subsequent revisions or patch sets.
> 2) I agree with Matt that the squashing to strictly one commit is not
> necessary. However more then 4 or 5 commit in the branch would become more
> then a little troublesome to use gerrit with. There should be certain
> guidelines for the individual commits though. Each commit should be focused,
> should compile and should not introduce a bug that are later fixed in a
> subsequent commit in the branch. If your topic consists of adding a new
> feature and fixing a bug and if these two items are dependent, it still
> could be good to have them separate. This way just the bug fix could be
> integrated.
> For example with Matthew's recent work on VTKImageIO2
> topic BUG0010725_VTKTensors2, he has a little bug fix and a new feature. The
> feature will require a little more work, but the bug fix I was able to
> cherry-pick so that it can be integrated right away.
> Additionally, some of my bug fixes topic I have created start with the first
> commit reproducing the bug as a test
> ( BUG0008524_StreamingImageRegionMultidimensionalSplitter). Then the next
> commit fixed the bug. I believe this also good programming practice of first
> writing the test for what you are about to do.
>
> Very nice work over all Dan!
> Brad
>
> On Sep 16, 2010, at 7:27 PM, Matthew McCormick (thewtex) wrote:
>
> Dan,
>>
>> http://www.itk.org/Wiki/ITK/Gerrit/Primer
>>
> Very nice.
> It seems that it is not necessary to squash a branch into a single commit,
> though, because of changes that were made to Gerrit?  When a topic branch is
> pushed, all commits in a branch are identified with a branch name in the
> commits overview.  This can be clicked to show all commits belonging to a
> branch.
> I have been learning Gerrit for the past couple of days while working with
> Brad King, aka Eagle Eye ;-).   After figuring it out, it is quite fun,
> primarily because it is such an efficient way to work and interact.
> Some things I stumbled over:
> - Keeping clear the difference between a git commit hash, a gerrit Change
> Id, and a gerrit change number.  The git commit hash is the sha hash that
> identifies the commit in git.  The gerrit Change Id looks similar, but it
> starts with an I.  It is used to identify the commit in gerrit.  There
> should be one, and only one, Change Id that lives at the end of a commit
> message.  The gerrit change number is a small number used to identify the
> commit when pushing to gerrit.
> - When replying to inline comments, they are only visible to the world after
> going to the commit's review page, hitting the 'Review' button, then hitting
> 'Publish Comments'.
> Matt
> <ATT00001..txt>
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
>