[vtk-developers] Gerrit conflicts

[Bill Lorensen]

It makes sense to me now. We need to document this process unless it
is already documented.

Also, I plan to have a separate clone of VTK (and ITK) called
VTKGerrit (and ITKGerrit). In this clone I'll do all of my reviews. Up
to now, I have been using my own VTK(ITK) clone. After I
review/build/test and go back to my master, I often have to rebuild a
lot of VTK(ITK). Does this make sense?

Bill

On Thu, Oct 14, 2010 at 3:54 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Thu, Oct 14, 2010 at 3:11 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> Here is what I've been doing in itk.
>>
>> I have an itk checkout that I track master with.
>> When I review something, I create a branch just for the purpose of
>> review. I checkout that branch.
>> Then I pull the gerrit I want to review. I build, test and enter my
>> comments into the review. When I'm done reviewing I delete the branch.
>>
>> So you are saying, I stay at master, then fetch I get this:
>> [VTK(master)] git fetch http://review.source.kitware.com/p/VTK
>> refs/changes/29/129/4 && git checkout FETCH_HEAD
>> From http://review.source.kitware.com/p/VTK
>>  * branch            refs/changes/29/129/4 -> FETCH_HEAD
>> Note: checking out 'FETCH_HEAD'.
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> changes and commit them, and you can discard any commits you make in this
>> state without impacting any branches by performing another checkout.
>>
>> If you want to create a new branch to retain commits you create, you may
>> do so (now or later) by using -b with the checkout command again. Example:
>>
>>  git checkout -b new_branch_name
>>
>> HEAD is now at bc7016e... ENH: Scripts to setup development environment.
>> [VTK((no branch))]
>> --------------------------------
>> Now I do my build/test to verify the review.
>>
>> To go back to master and discard the fetched review code I
>>
>> git checkout master
>>
>> Or I can retain the fetched review code in a branch with:
>>
>> git checkout -b UsefulSetupScripts
>>
> That is how I use Gerrit, and is how I would recommend you review code. It
> means you have the tree in the state the submitter proposed, whereas your
> approach merges their changes into whatever your local master happens to be
> at. It also has the advantage that there is no local branch to delete unless
> you choose to create one for further review/pushing to the topic stage (for
> external contributions).
> Hopefully that makes sense to you.
> Marcus