[Insight-developers] Gerrit / git primer

Fri Sep 17 11:51:36 EDT 2010

hi dan,

that was a wonderfull job, and very well illustrated. I think it will
make it easier to rbing in new people thanks to it.

Now, I also think we should separate user workflow (which you
covered), reviewer workflow and itk developper workflow, but
eventually I hope there will be such an easy, illustrated, workflow
for each of those.

Different people have different mileage: here is where I stand today,
and I love to go all the way:
User basic - OK
- clone,
- branch,
- modify,
- test,
- pull from origin master,
- test,
- squeeze commits into 1,
- push to github/gerrit

User advanced / reviewer - not yet
- branch??
- pull from gerrit ??
- review
- test

ITK developer - not yet
- pull branch from remote (gerrit?)
- merge stage into branch ?
- merge into stage ?
- print ?
- what about release and master?

any help / hints appreciated.

alex.

On Fri, Sep 17, 2010 at 3:39 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> 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
>>
>>
> _______________________________________________
> 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
>