[vtk-developers] Gerrit conflicts

[Bill Lorensen]

Marcus,

I agree completely that gerrit is the way to go. Just in my limited
exposure with it in ITK, I think fills a gap in code review that we
never had. By the time code gets checked into the main repository,
it's almost too late because there are only a few people that even
look at the dashboards and and even fewer number that will try and fix
problems.

Both gerrit and git have tremendous flexibility. Our challenge is to
provide best practices for using them effectively.

Bill


On Thu, Oct 14, 2010 at 4:41 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> 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.
> Marcus
> On Thu, Oct 14, 2010 at 4:30 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> 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
>
>