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

[Marcus D. Hanwell]

2010/10/16 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>

>
> Le 15 oct. 10 à 23:51, Gaëtan Lehmann a écrit :
>
>>
>> I'm working on the integration in ITK of the rest of my contribution
>> "Label object representation and manipulation with ITK". I already have 25
>> commits - one per new class with its tests - and a few more to come.
>>
>> I don't want to merge all those commits in a single one - I think they are
>> quite logical that way, and a huge commit would be quite hard to review in
>> gerrit - but I'm afraid such a set of commits in gerrit wouldn't be much
>> usable.
>>
>
> I've pushed my commits to github, if someone wants to see how it looks
>
>  http://github.com/glehmann/ITK/commits/labelmap
>
>
>> What would be the best way to go?
>>
>> Sorry, the work day had to end sometime. This is where Brad and I would
really like to work with the Gerrit developers on improving Gerrit. Large
topic branches are still more cumbersome than we would like to deal with. In
truth though, any large code drop is difficult to deal with whether it is as
one huge commit, or a patch series. I would rather deal with it as a patch
series.

git diff --stat origin/master..glehmann/labelmap

That command shows 89 files changed, 7781 insertions(+), 1260 deletions(-).

git log --oneline origin/master..glehmann/labelmap | wc -l

That gives me the 23 commits in the topic branch, and they look like a
logical progression. Anyone reviewing this topic branch could just follow
the "Needed-by" chain to its end, and then copy+paste the checkout line to
get your entire topic branch. They could then review it locally, and work
through each of the commits in the series.

We can make the interface more streamlined for larger topic branches, but
any large topic will be challenging and will likely involve looking at any
changes to critical classes, ensuring tests were added and checking whether
it builds and/or causes regressions in the test suite. Large changes like
this are necessary at times, but will always present a challenge to
reviewers.

I hope that helps clear things up a little. In conclusion it may be easier
for the reviewers to look over the entire squashed topic branch due to
reduce number of clicks. If they intend to fully review all of the changes
then the time to review each commit will be smaller than the time to click
through the review interface.

Marcus
--
Marcus D. Hanwell, Ph.D.
R&D Engineer, Kitware Inc.
(518) 881-4937
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20101016/9277b40d/attachment-0001.htm>