On Wed, Mar 7, 2012 at 1:12 AM, David Soria Parra <d...@php.net> wrote:
> On 2012-03-07, Kris Craig <kris.cr...@gmail.com> wrote: > > --f46d044304ec4e135704baa12342 > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes <ki...@managedit.ie> > wrote: > > > >> On Wed, Mar 7, 2012 at 6:03 AM, Drak <d...@zikula.org> wrote: > >> > > I know I keep promising to draft an RFC for this lol, so I'll make it a > > high priority to put together an RFC for a PHP Git branching model > sometime > > this week[end]. > > There is no need for that. PHP will continue to use release branches > with optional feature branches. We are doing one step at a time and > have people adopt the changes slowly. We are after all a large project > and a lot of contributors cannot spend hours of reading into a VCS > and a new branching model. So we are slowly moving towards new models. > > After all I see no need to do it differently. You can use whatever > branching model you want in your personal github repository and then > send a final pull request that can be merged. Adding complexity > to the main repository for no reason is not needed. Keep the > complexity in your personal repositories. That is after all > one of the main benefits of a decentralized version control system. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > A few points.... 1. This really wouldn't be adding "complexity" to the repo. We would merely be using a branching model that is more compatible with Git's feature set. As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. We may as well just keep using SVN if we're not going to make use of Git's branching advantages. 2. Using different branching structures between repo clones is not considered a good practice in Git. On the contrary, it just makes the commit history that much more confusing to read. If you use a standardized branching model, on the other hand, different features/contributions can be quickly and easily identified in the history (see "gitk --all"). In the event of a regression or other bad feature commit, reversing it is *much*easier and cleaner if branches are clearly segregated. It also makes drafting the changelog a much less cumbersome task. 3. I'm all for using a gradual approach so that people have time to get used to it. However, that transition to a standards-compliant Git branching model is still something that does need to happen eventually. 4. Git branching is not *nearly* as complicated or confusing as you guys are making it out to be. You know how long it took me to train our IT guy at work on Git branching? 10 minutes. He then made one mistake (forgot the --no-ff), which I corrected, and ever since he's been using it without any problems and raving about how much easier it is to keep track of our commit history now than when we were on Subversion. Seriously, the learning curve is *very* minimal, even for those who are used to SVN branching. 5. Enough people have expressed support for this idea to justify drafting an RFC and letting it be voted on IMHO. However, I would like to address your concerns about confusion (though experience tells me that they're largely unfounded), so when I draft it I'll propose a gradual adoption scheme of some sort so that anyone who feels intimidated by adhering to mainstream accepted Git branching standards won't feel disenfranchised. 6. There are also scripts that simplify this model ( https://github.com/nvie/gitflow), though I've never used them myself. But I'll take a look and see if that might be something that could be recommended for anyone who doesn't want to spend the few minutes it would take to learn t his model. --Kris
