On 06/23/2011 06:02 PM, Brad King wrote: > On 06/23/2011 10:36 AM, Michael Wild wrote: >> On 06/23/2011 04:11 PM, Brad King wrote: >>> We manually select topics from 'next' and merge them to 'master'. >>> Only topics in master will be released. >> >> So, how does that work? Do you look for the merges in 'next' that you >> like, and then re-merge them to 'master' directly from the topic-branch? > > Yes. The complete workflow is described generically here: > > http://public.kitware.com/Wiki/Git/Workflow/Topic > > We use a "topic stage" repository to keep explicit topic branch heads > that are not in all integration branches: > > http://public.kitware.com/Wiki/Git/Workflow/Stage > > CMake's topic stage is published here: > > http://cmake.org/stage/cmake.git > > The set of branches changes regularly as topics are added or finished. > >> Something like this? >> >> -- A ------------------------ I -- master >> \ \ \ / >> \ \ C --- D ------ G -- topic2 >> \ \ \ >> \ B -- D -- topic1 \ >> \ \ \ >> \------- F ------------H -- next > > Yes, exactly. > >> i.e. everything starts at A, 'master' and 'next' being identical. Then, >> someone creates 'topic1' and merges it into 'next' (commit F). >> Meanwhile, another topic, 'topic2' is created, and also merged into >> 'next' (commit H). Now, 'topic1' just isn't ready, but 'topic2' is, so >> it gets merged into 'master' (commmit I). Is this correct? > > Yes. It gets a little more complicated when there are conflicts: > > http://public.kitware.com/Wiki/Git/Workflow/Topic/Conflicts > >> Is 'next' kind of your "throw-away" integration branch? > > Yes. No topics are allowed to see any of the merges into next. There > is even a check on the server that disallows topics (or master) to see > the beginning of next. > >> Do you rebase it regularly onto master? > > So far we haven't rewritten it but the workflow allows that because > nothing should be based on it. Currently we have to avoid rewriting > the branch because some dashboard clients may do just "git pull" to > update. Recent CTest versions do a fetch & reset so that they can > handle upstream rewrites. > > I designed all of the above after reading about Git's own workflow: > > > http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/maintain-git.txt;hb=v1.7.5 > > Our "topic stage" takes the place of the maintainer's private repository. > I designed it to help distribute some of the maintainer's workload among > developers (and they don't even have to know; it's just part of their > workflow). > > -Brad
Thanks for the thorough explanation. I have to say, it is very well thought-through, I'll try to enforce something similar for my projects. gitworkflows(7) always seemed a bit unwieldy to me, but then it is also geared towards much larger projects with many more contributors... Michael _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
