<div>Yes, you are mainly doing that so that the file timestamps are not always changing, causing the rebuilds. I will work on documenting this and clearing up any confusion in the ITK community especially, as well as finding a good path forward for the VTK community. I think that Gerrit will be an ideal path for integrating changes from the community.</div>
<div><br>Marcus</div><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 4:30 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It makes sense to me now. We need to document this process unless it<br>
is already documented.<br>
<br>
Also, I plan to have a separate clone of VTK (and ITK) called<br>
VTKGerrit (and ITKGerrit). In this clone I'll do all of my reviews. Up<br>
to now, I have been using my own VTK(ITK) clone. After I<br>
review/build/test and go back to my master, I often have to rebuild a<br>
lot of VTK(ITK). Does this make sense?<br>
<br>
Bill<br>
<br>
On Thu, Oct 14, 2010 at 3:54 PM, Marcus D. Hanwell<br>
<div class="im"><<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> On Thu, Oct 14, 2010 at 3:11 PM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Here is what I've been doing in itk.<br>
>><br>
>> I have an itk checkout that I track master with.<br>
>> When I review something, I create a branch just for the purpose of<br>
>> review. I checkout that branch.<br>
>> Then I pull the gerrit I want to review. I build, test and enter my<br>
>> comments into the review. When I'm done reviewing I delete the branch.<br>
>><br>
>> So you are saying, I stay at master, then fetch I get this:<br>
>> [VTK(master)] git fetch <a href="http://review.source.kitware.com/p/VTK" target="_blank">http://review.source.kitware.com/p/VTK</a><br>
>> refs/changes/29/129/4 && git checkout FETCH_HEAD<br>
>> From <a href="http://review.source.kitware.com/p/VTK" target="_blank">http://review.source.kitware.com/p/VTK</a><br>
>>  * branch            refs/changes/29/129/4 -> FETCH_HEAD<br>
>> Note: checking out 'FETCH_HEAD'.<br>
>><br>
>> You are in 'detached HEAD' state. You can look around, make experimental<br>
>> changes and commit them, and you can discard any commits you make in this<br>
>> state without impacting any branches by performing another checkout.<br>
>><br>
>> If you want to create a new branch to retain commits you create, you may<br>
>> do so (now or later) by using -b with the checkout command again. Example:<br>
>><br>
>>  git checkout -b new_branch_name<br>
>><br>
>> HEAD is now at bc7016e... ENH: Scripts to setup development environment.<br>
>> [VTK((no branch))]<br>
>> --------------------------------<br>
>> Now I do my build/test to verify the review.<br>
>><br>
>> To go back to master and discard the fetched review code I<br>
>><br>
>> git checkout master<br>
>><br>
>> Or I can retain the fetched review code in a branch with:<br>
>><br>
>> git checkout -b UsefulSetupScripts<br>
>><br>
> That is how I use Gerrit, and is how I would recommend you review code. It<br>
> means you have the tree in the state the submitter proposed, whereas your<br>
> approach merges their changes into whatever your local master happens to be<br>
> at. It also has the advantage that there is no local branch to delete unless<br>
> you choose to create one for further review/pushing to the topic stage (for<br>
> external contributions).<br>
> Hopefully that makes sense to you.<br>
> Marcus<br>
</div></div></blockquote></div><br>