[Insight-developers] Gerrit / git primer

[Bradley Lowekamp]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100917/27ab8b4a/attachment.htm>