On 5. Jun, 2010, at 17:46 , Miguel A. Figueroa-Villanueva wrote: > On Thu, May 13, 2010 at 11:47 AM, Brad King wrote: >> Hi Folks, >> >> We are about to switch to a branchy, topic-based workflow for CMake >> development with Git. The approach is based on a workflow documented >> in "git help workflows". We've written a Wiki page to document it: >> >> http://public.kitware.com/Wiki/Git/Workflow/Topic >> >> along with step-by-step development instructions. Please read this >> carefully before doing any development after the transition to the >> new workflow. > > Hello Everyone, > > I was reading along the wiki page on the new workflow and in an effort > to understand things better I would like to have someone clarify > something about the "avoid the urge to merge" statement. That is, I > understand the concept and why it is necessary to keep the history > shape cleaner. > > However, one could have a balance that satisfies both the "urge to > merge" and the clean history by rebasing the topic branch to the > current master, right? > > That would change the sequence of commands to something like this > (bear in mind that I'm not familiar with git, but it should be close): > > # create your topic branch > git checkout master > git checkout -b topic > > # do work > git commit > git commit > > # rebase to make merging to next easier > git pull > git rebase master > > # continue work > git commit > git commit > > # finally publish your topic branch > git checkout next > git merge topic > git push > > Of course, this is assuming that the topics (next branch) are merged > into master frequently. Also, it is only worth it if you are working > on a feature that takes a long time to develop (otherwise the merge > will be simple enough without rebasing). Does this make sense or am I > missing something about how git or the new workflow works? > > Thanks, > --Miguel
IMHO rebasing is great to keep things up to date when developing a topic. But make sure to _NEVER_ rebase a commit you published before. That's going to create a lot of trouble. If you read "man gitworkflows" you will see that this is not a hard rule, e.g. the git developers themselves use a "throw-away" integration branch they call "pu" (proposed updates). At well defined points in the development cycle they clean up its history by rebasing/squashing/splitting and then merge it into "next". After that a new "pu" branch is created. HTH Michael _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
