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 git@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 <steve(a)hibernate.org>
http://hibernate.org