On Thursday, October 07, 2010 01:51:52 pm Steve Ebersole wrote: > On Thursday, October 07, 2010 04:30:11 am Emmanuel Bernard wrote: > > If you want to contribute a fix or new feature, either use the pure Git > > approach, or use the GitHub fork capability (see > > http://help.github.com/forking/ and http://help.github.com/pull-requests/ > > ) The benefit of the GitHub approach is that we can comment on the pull > > request and code though I am far from an expert so far and their flow > > could easily be improved (slightly confusing). > > > > #for people with read/write access > > git clone g...@github.com:hibernate/hibernate-core.git > > The "GitHub" way though is to fork the org repo and clone that. I thought > that's the workflow we agreed to follow?
Actually having played with this for a few days now I can say that this fork/clone approach feels like just extra steps for which I cannot see the benefit. I should have stuck to my guns initially and not let you talk me into fork/clone ;) > > > o prefer rebase over merge > > Rebase put changes from the branch you forked below the new commits you > > have done and thus keep the history linear. > > > > got checkout HHH-XXX > > git rebase master > > > > DO NOT rebase a branch that you have shared publicly (unless you know > > people won't use it or you wish them harm). > > These 2 comments seem at odds in regards to bugfix branches (aka '3.2', > '3.3' and '3.5' currently). -- Steve Ebersole <st...@hibernate.org> http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
