[vtk-developers] Preventing conflicts in the new workflow

[Marcus D. Hanwell]

On Thu, Oct 14, 2010 at 9:34 PM, David Doria <daviddoria at gmail.com> wrote:

> A situation came up on the users list today which sparked a
> hypothetical question. There was a small issue with a function that
> two people agreed should be fixed. I have a topic branch that happens
> to deal with that function, so I was planning on adding the fix to the
> existing topic. If I hadn't mentioned that I was doing that, person B
> may have made their own topic branch just for this fix and merged it
> with master. Then when I go to merge my topic when it is finished,
> there would likely be a conflict.
>
> With the old "push directly to master" system, you would pull the
> latest version (the cvs mindset), then make changes to that. So, as
> long as person A and person B don't do this at physically the same
> time there won't be a problem. With the new system, person B would
> have to know about the branch that person A is working on in order to
> check if the fix has already been applied there. Once there are more
> than a handful of topic branches, keeping track of who is working on
> what will be tricky.
>

There is very little difference between this situation, and the previous
situation...with CVS you would have fixed it locally, continued working on
what you were doing and then updated before committing. Now you continue
working, but commit this fix with a meaningful commit message telling us
what you did.

Please remember that these are 'topic branches', and should encapsulate
topics - you should not bundle in random fixes. If it is a trivial fix,
unrelated to your topic, then it would be better to,

git checkout -b bug-fix-topic origin/master

Fix the bug on that topic branch, stage, merge and then switch back to the
topic branch you were previously working on. This is one fo the major
advantages of the branchy workflow - you can work on meaningful topics, if a
bug is discovered and you need to fix it switch to a new topic, fix it and
get back to what you were doing.

There is always scope for conflicts, no matter what strategy is used. If you
are making large changes then announcing what you are working on to the
community is always good form. Conflicts will happen, and git gives us great
tools to resolve them when they occur.

Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20101014/9bb3b1d1/attachment.html>