Hi all, James pointed me to this great discussion on workflow around git:
http://kerneltrap.org/Linux/Git_Management I've been slowly arriving at Linus's conclusion -- development always happens in topic branches, and that development makes its way to the "main" branches (e.g., master and 0.24.x) by having the branch maintainer do the merge. Also, topic branches could and should rebase against their original branch, but the branch maintainer should never rebase. For instance, I recently did some provider refactoring in the 0.24.x branch, which James now maintains. What I should have done is this: * branch 0.24.x * do my development in the new branch * if the 0.24.x branch has changed in the meantime, pull 0.24.x from James and rebase against it * publish my new branch (but *don't* merge it into 0.24.x) and ask James to pull * when I see the code has been merged by James, delete my topic branch This way patches always flow from developers to maintainers, and largely, the only one ever doing a merge is the maintainer. Anyone opposed to trying this out? For most people, I expect the only real differences would be that you would never publish your own 0.24.x branch except as a duplicate of James's, and you would periodically need to rebase your topic branch against whatever you originally branched. -- Tradition is what you resort to when you don't have the time or the money to do it right. -- Kurt Herbert Alder --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
