[vtk-developers] ANN: All VTK commits through the topic stage

[Marcus D. Hanwell]

On Tuesday 12 October 2010 18:16:15 David Doria wrote:
> On Tue, Oct 12, 2010 at 4:17 PM, Marcus D. Hanwell <
> 
> marcus.hanwell at kitware.com> wrote:
> > Hi,
> > 
> > As previously announced on September 23, the VTK topic stage is available
> > to
> > merge in topic branches. From Thursday October 14 all commits to VTK will
> > need
> > to be made through the topic stage, and direct pushes to the VTK
> > repository will be disabled.
> 
> Should directly pushing to master be removed all together? What about
> little bug fixes? It seems crazy to make a topic branch just to push a one
> line change.
> 
If you think like a CVS user then yes, but topic branches are just named 
pointers to a hash. Also, consider the case where you fixed your bug, you 
pushed, and then realized you had not accounted for how it works on Windows, 
then you push another commit and we now have no way of connecting those two 
commits together.

Further, consider we want to backport your fix to the next VTK bug fix release, 
but we only spot the first commit (not the next one you made a week later). Or, 
we only spot the second and miss the first. Both of these cases have happened 
in VTK with the bug fix releases and caused lots of headaches.

It gets people used to using the stage, and where it is really required is 
when we switch to using master *and* next. In order to merge a change into 
next, see if it works, and then merge the same change into master, the only 
viable workflow is the branchy workflow we have discussed. Merge commits are 
necessary to show the point at which the commit was merged into next, and 
later master.

http://public.kitware.com/Wiki/Git/Workflow/Stage

That wiki page details some of the motivation behind this. We want to move to 
a workflow where people land complete features. It also allows us to use code 
review tools such as Gerrit if we wish, and have all of the commit objects 
resolve to being the same thing without the rebasing necessary in a linear 
workflow.

Hopefully this clears up some of the motivation for you. As I said to you in a 
private email, there is a Source article in the upcoming October issue, along 
with several wiki pages. Reading 'man gitworkflows' might also be useful.

Marcus
-- 
Marcus D. Hanwell, Ph.D.
R&D Engineer, Kitware Inc.
(518) 881-4937