[Insight-developers] Gerrit, Git, aliases and squashing commits

[Bill Lorensen]

Marcus,

If the documentation on the wiki is wrong or misleading, then we
should change it. Many of us have no idea what is going on, a few of
us think we know what is going on and a couple of you know what is
going on.

We rely on the experts to keep us on track.

Thanks,

Bill

On Fri, Oct 15, 2010 at 1:53 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Hi,
> I was going through some of the instructions on the ITK community concerning
> Gerrit and staging changes. I will talk more about this at the ITK meeting
> in November, but I don't think you should be squashing commits before
> sending them to Gerrit unless you also intend to merge them into ITK in that
> form. Gerrit is offering us review of commits before they go into our
> repository, and the opportunity to fix these commits before they are merged.
> If you think there are too many micro-commits to push to Gerrit then I would
> argue there are too many to push into our repository. The whole point of
> retaining history is so that people can also go in after the fact and review
> previous commits for various reasons. Gerrit tracks the dependencies of
> commits in a topic branch, you can look at a patch's dependencies and follow
> needed-by until you reach the end of a topic branch. You can then copy/paste
> the checkout line, and even make it into a local topic branch with the same
> name,
> git fetch http://review.source.kitware.com/p/ITK refs/changes/61/161/1 &&
> git checkout FETCH_HEAD
> git checkout -b GitAliases
> Using the simple command line below you can see what commits you have that
> are not yet merged into master,
> git log --oneline --graph origin/master..
> You can then compile and test these changes (if necessary), and even stage
> this topic branch in the case of commits coming from the community. Using
> the new aliases,
> git stage-push
> To merge the topic,
> git stage-merge
> Gerrit certainly needs some work to make topic branches simpler to deal with
> in the interface, but this level of interaction is already possible. It is
> how I work with Gerrit, and I have reviewed several lengthy topic branches
> using this workflow. I also wanted to point out that if you have Change-Id
> inserted as the last line of your commit message then,
> git push stage HEAD:refs/for/master
> Would be enough to update any commits you have changed on your topic branch,
> as Gerrit uses the Change-Id lines to resolve the newly pushed commits to
> the ones it has seen and update the patch sets accordingly. Thus, making it
> very simple to push an updated topic branch and keep all dependencies
> consistent.
> Hopefully this makes a few things clearer, I will be listening out for any
> more feedback/issues and look forward to meeting some of you at the ITK
> meeting.
> Marcus
> --
> Marcus D. Hanwell, Ph.D.
> R&D Engineer, Kitware Inc.
> (518) 881-4937
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
>