[vtk-developers] Gerrit conflicts

Marcus D. Hanwell marcus.hanwell at kitware.com
Thu Oct 14 16:41:50 EDT 2010


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20101014/af6d7f86/attachment.html>


More information about the vtk-developers mailing list