[Insight-developers] [master] Change Ie2bca991: (ITK) STYLE: improved style on a couple sets of if statements

[Bradley Lowekamp]

On Aug 30, 2010, at 11:00 AM, Brad King wrote:

> On 08/30/2010 10:50 AM, Luis Ibanez wrote:
>> I guess I'm struggling between these two conflicting goals:
>> 
>>   A) Used this case as a dry-run of the Gerrit workflow
> 
> Conflict-ridden development paths are not a good test case for
> Gerrit.  Even if we had configured things so Gerrit could do the
> merge, it refuses to do any merges change the same files even
> if the changes do not conflict.
> 
>>   B) Fix the JPEG2000 code and move forward.
>> 
>> I'm leaning towards (B) at this point, mostly because there
>> are many other things in our plates, and we are spending
>> too much time in taking care of something that should have
>> been a simple procedure.
>> 
>> I don't mind if the commits are different due to the rebase,
>> since they will still be authored by you.
> 
> The reference to Gerrit can be preserved if Brad L. rewrites
> his commits to include the gerrit Change-Id lines.  This is
> actually as simple as fetching the branch from Gerrit because
> it always rewrites commit messages to add the lines.  Once
> those lines are in the messages the commits can be rebased
> or merged freely.

I am not getting the Change-Id automatically added to my fetches from gerrit.
I used the following to fetch:

git fetch http://review.source.kitware.com/p/ITK refs/changes/27/27/1 && git checkout FETCH_HEAD

I also tried other proposed patches which out success. Given that I have 4 patches to update, if this could happen automatically it'd be sweet!

This is the hook on the review git repository which should do it?
http://gerrit.googlecode.com/svn/documentation/2.0/user-changeid.html#creation

Out of curiosity would this also change the SHA?

Thanks,
Brad


> 
>> Brad K.: here is the situation:  Brad L. have a set of fixes
>> for JPEG2000 that he pushed to Gerrit. In the meantime
>> a number of changes have happened in the master, that
>> are making harder to integrate his fixes.  I'm wondering
>> if rebase is an option here...
> 
> If the changes are ready and do not already conflict with
> master then Brad L. can use the topic stage to merge.  Real
> merges are usually preferable to rebasing because it preserves
> a record of the real paths of development.
> 
> Brad L, if the changes conflict and the stage refuses to
> merge, you can first merge 'master' into your topic to resolve
> the conflicts locally.  Then the topic stage can merge it
> back to master without trouble.  Just be sure your merge
> from master documents in its message what it is doing.
> 
> -Brad K

========================================================
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/20100830/c142302f/attachment.htm>