Hibernate Core now uses Git as the version control system. You can access it at http://github.com/hibernate/hibernate-core Core on Git We have imported the SVN history (at least what GIT could extract) and pushed the SVN trunk, branch 3.5 and branch 3.3. If you need more of the legacy branches or tags, let me know, that can be arranged. 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). If you still want to do it the old way a provide a patch file, that's ok too. Tips on Git Here are some tips on Git: o read Pro Git http://progit.org/book/ awesome book and very practical. It has a free html and epub version (buying the tree version is recommended to repay the author). o prefer the git protocol when cloning over http (so say the experts). At the very least that will be much faster. cloning the repo from GitHub took me less than 3 minutes #for people with read/write access git clone git@github.com:hibernate/hibernate-core.git #for people with read-only access git clone git://github.com/hibernate/hibernate-core.git It will create a "remote" link named origin. I usually tend to rename it to reflect what it is really. git remote rename origin core-on-github o always work on a topic branch and merge your work when you are done git checkout master git checkout -b HHH-XXX hack commit hack commit Likewise if you want to share a work with somebody from the Hibernate team, push or define the pull request of your topic branch (though make sure your topic branch is above master). o prefer small commits, they will be more readable and will very unlikely fail on merge o write good comments (short one line including the issue at stack followed by a blank line and a more detailed explanation if needed) `HHH-XXX Fix NPE on persist Fix stupid bug by Gavin that lead to a NPE when persisting objects with components` 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). o while you are at rebasing, you can rewrite your commit history to clean comments or merge some commits together (named squashing) git rebase -i HEAD~6 (go back 6 commits in time) o once you're fed up with typing longish command lines, use aliases (see below) o I've put a copy of my ~/.gitconfig file in case people want to copy some things including aliases (see below) o if you use Mac OS X, GitX is a fantastic tool, in particular to do interactive staging and commit only some parts of a file o you can read this blog entry that was some more info http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-sinc... o feel free to add your tips to this email thread, I'll likely compile them in a blog entry. ~/.gitconfig [user] name = Redacted email = redacted(a)redacted.com signingkey = id_key.pub [core] editor = open -nW -a Smultron [merge] tool = opendiff [color] ui = auto [color "branch"] current = yellow reverse local = yellow remote = green [color "diff"] meta = yellow bold frag = magenta bold old = red bold new = green bold [color "status"] added = yellow changed = green untracked = cyan [github] user = redacted token = redacted [alias] co = checkout undo = reset --hard cb = checkout -b br = branch cp = cherry-pick _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

We cannot forget to update the info on hibernate.org and the wiki. I was just about to find the pages in need of updated, but it seems the wiki is down :( --Hardy On Thu, 07 Oct 2010 11:30:11 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > Hibernate Core now uses Git as the version control system. > You can access it at http://github.com/hibernate/hibernate-core > > Core on Git > > We have imported the SVN history (at least what GIT could extract) and > pushed the SVN trunk, branch 3.5 and branch 3.3. If you need more of the > legacy branches or tags, let me know, that can be arranged. > > 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). > > If you still want to do it the old way a provide a patch file, that's ok > too. > > Tips on Git > Here are some tips on Git: > > o read Pro Git http://progit.org/book/ awesome book and very practical. > It has a free html and epub version (buying the tree version is > recommended to repay the author). > > o prefer the git protocol when cloning over http (so say the experts). > At the very least that will be much faster. cloning the repo from GitHub > took me less than 3 minutes > > #for people with read/write access > git clone git@github.com:hibernate/hibernate-core.git > > #for people with read-only access > git clone git://github.com/hibernate/hibernate-core.git > > It will create a "remote" link named origin. I usually tend to rename it > to reflect what it is really. > git remote rename origin core-on-github > > o always work on a topic branch and merge your work when you are done > git checkout master > git checkout -b HHH-XXX > hack commit hack commit > > Likewise if you want to share a work with somebody from the Hibernate > team, push or define the pull request of your topic branch (though make > sure your topic branch is above master). > > o prefer small commits, they will be more readable and will very > unlikely fail on merge > > o write good comments (short one line including the issue at stack > followed by a blank line and a more detailed explanation if needed) > `HHH-XXX Fix NPE on persist > > Fix stupid bug by Gavin that lead to a NPE when persisting objects with > components` > > 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). > > o while you are at rebasing, you can rewrite your commit history to > clean comments or merge some commits together (named squashing) > git rebase -i HEAD~6 (go back 6 commits in time) > o once you're fed up with typing longish command lines, use aliases (see > below) > > o I've put a copy of my ~/.gitconfig file in case people want to copy > some things including aliases (see below) > > o if you use Mac OS X, GitX is a fantastic tool, in particular to do > interactive staging and commit only some parts of a file > > o you can read this blog entry that was some more info > http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-sinc > e-last-month-when-i-used-svn/ > > o feel free to add your tips to this email thread, I'll likely compile > them in a blog entry. > > > > ~/.gitconfig > [user] > > name = Redacted > email = redacted(a)redacted.com > signingkey = id_key.pub > > [core] > > editor = open -nW -a Smultron > > [merge] > > tool = opendiff > > [color] > > ui = auto > > [color "branch"] > > current = yellow reverse > local = yellow > remote = green > > [color "diff"] > > meta = yellow bold > frag = magenta bold > old = red bold > new = green bold > > [color "status"] > > added = yellow > changed = green > untracked = cyan > > [github] > > user = redacted > token = redacted > > [alias] > > co = checkout > undo = reset --hard > cb = checkout -b > br = branch > > cp = cherry-pick > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Adding to the favorite git tools: Command completion support (git-completion.bash) is pretty good if your a command shell type person. The script is available via Git project source and other places (included in Fedora). If you read the below mentioned progit book (just ordered my copy last week :), you will have read http://progit.org/book/ch2-11.html which talks about git-completion.bash. There are various GUIs but gitk is my favorite so far. On Thu, 2010-10-07 at 11:30 +0200, Emmanuel Bernard wrote: > Hibernate Core now uses Git as the version control system. > You can access it at http://github.com/hibernate/hibernate-core > > Core on Git > > We have imported the SVN history (at least what GIT could extract) and pushed the SVN trunk, branch 3.5 and branch 3.3. If you need more of the legacy branches or tags, let me know, that can be arranged. > > 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). > > If you still want to do it the old way a provide a patch file, that's ok too. > > Tips on Git > Here are some tips on Git: > > o read Pro Git http://progit.org/book/ awesome book and very practical. It has a free html and epub version (buying the tree version is recommended to repay the author). > > o prefer the git protocol when cloning over http (so say the experts). At the very least that will be much faster. cloning the repo from GitHub took me less than 3 minutes > > #for people with read/write access > git clone git@github.com:hibernate/hibernate-core.git > > #for people with read-only access > git clone git://github.com/hibernate/hibernate-core.git > > It will create a "remote" link named origin. I usually tend to rename it to reflect what it is really. > git remote rename origin core-on-github > > o always work on a topic branch and merge your work when you are done > git checkout master > git checkout -b HHH-XXX > hack commit hack commit > > Likewise if you want to share a work with somebody from the Hibernate team, push or define the pull request of your topic branch (though make sure your topic branch is above master). > > o prefer small commits, they will be more readable and will very unlikely fail on merge > > o write good comments (short one line including the issue at stack followed by a blank line and a more detailed explanation if needed) > `HHH-XXX Fix NPE on persist > > Fix stupid bug by Gavin that lead to a NPE when persisting objects with components` > > 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). > > o while you are at rebasing, you can rewrite your commit history to clean comments or merge some commits together (named squashing) > git rebase -i HEAD~6 (go back 6 commits in time) > > o once you're fed up with typing longish command lines, use aliases (see below) > > o I've put a copy of my ~/.gitconfig file in case people want to copy some things including aliases (see below) > > o if you use Mac OS X, GitX is a fantastic tool, in particular to do interactive staging and commit only some parts of a file > > o you can read this blog entry that was some more info http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-sinc... > > o feel free to add your tips to this email thread, I'll likely compile them in a blog entry. > > > > ~/.gitconfig > [user] > name = Redacted > email = redacted(a)redacted.com > signingkey = id_key.pub > [core] > editor = open -nW -a Smultron > [merge] > tool = opendiff > [color] > ui = auto > [color "branch"] > current = yellow reverse > local = yellow > remote = green > [color "diff"] > meta = yellow bold > frag = magenta bold > old = red bold > new = green bold > [color "status"] > added = yellow > changed = green > untracked = cyan > [github] > user = redacted > token = redacted > [alias] > co = checkout > undo = reset --hard > cb = checkout -b > br = branch > cp = cherry-pick > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi all, I think this is a good thing to have Hibernate on github. I just forked and did a few modifications (I'm learning git at the same time). I also did my first pull request ;) to validate the process. This is very minor modification so I didn't open an issue on JIRA. Regards, Julien ----- Message d'origine ---- > De : Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > À : hibernate-dev(a)lists.jboss.org > Envoyé le : Jeu 7 octobre 2010, 11h 30min 11s > Objet : [hibernate-dev] Hibernate Core is now using Git > > Hibernate Core now uses Git as the version control system. > You can access it at http://github.com/hibernate/hibernate-core > > Core on Git > > We have imported the SVN history (at least what GIT could extract) and > pushed > >the SVN trunk, branch 3.5 and branch 3.3. If you need more of the legacy >branches or tags, let me know, that can be arranged. > > 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). > > If you still want to do it the old way a provide a patch file, that's ok > too. > > Tips on Git > Here are some tips on Git: > > o read Pro Git http://progit.org/book/ awesome book and very practical. > It has > >a free html and epub version (buying the tree version is recommended to >repay the author). > > o prefer the git protocol when cloning over http (so say the experts). > At the > >very least that will be much faster. cloning the repo from GitHub took me >less than 3 minutes > > #for people with read/write access > git clone git@github.com:hibernate/hibernate-core.git > > #for people with read-only access > git clone git://github.com/hibernate/hibernate-core.git > > It will create a "remote" link named origin. I usually tend to rename it > to > >reflect what it is really. > > git remote rename origin core-on-github > > o always work on a topic branch and merge your work when you are done > git checkout master > git checkout -b HHH-XXX > hack commit hack commit > > Likewise if you want to share a work with somebody from the Hibernate > team, > >push or define the pull request of your topic branch (though make sure >your topic branch is above master). > > o prefer small commits, they will be more readable and will very > unlikely fail > >on merge > > o write good comments (short one line including the issue at stack > followed by > >a blank line and a more detailed explanation if needed) > > `HHH-XXX Fix NPE on persist > > Fix stupid bug by Gavin that lead to a NPE when persisting objects with > >components` > > 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). > > o while you are at rebasing, you can rewrite your commit history to > clean > >comments or merge some commits together (named squashing) > > git rebase -i HEAD~6 (go back 6 commits in time) > > o once you're fed up with typing longish command lines, use aliases (see > >below) > > o I've put a copy of my ~/.gitconfig file in case people want to copy > some > >things including aliases (see below) > > o if you use Mac OS X, GitX is a fantastic tool, in particular to do > >interactive staging and commit only some parts of a file > > o you can read this blog entry that was some more info > >http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-since >-last-month-when-i-used-svn/ > > o feel free to add your tips to this email thread, I'll likely compile > them in > >a blog entry. > > ~/.gitconfig > [user] > > name = Redacted > email = redacted(a)redacted.com > > signingkey = id_key.pub > > [core] > > editor = open -nW -a Smultron > > [merge] > > tool = opendiff > > [color] > > ui = auto > > [color "branch"] > > current = yellow reverse > > local = yellow > > remote = green > > [color "diff"] > > meta = yellow bold > frag = magenta bold > old = red bold > new = green bold > > [color "status"] > > added = yellow > changed = green > untracked = cyan > > [github] > > user = redacted > > token = redacted > > [alias] > > co = checkout > undo = reset --hard > cb = checkout -b > br = branch > > cp = cherry-pick > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

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).

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&gt; http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hey Paul On Thursday, October 07, 2010 07:23:31 pm Paul Benedict wrote: > I missed the behind-the-scenes discussion. Why was SVN booted? We generally discuss stuff like this at our weekly dev meetings on irc. > And can > I still submit SVN diff patches? I personally do not know how to apply an SVN diff against Git. Or at least I have not tried to see if it will work (pretty sure patch can apply diffs produced by SVN). The other option you have is to move the work over to a GitHub fork of the main hibernate repo, reapply your changes (either copy them in place or using patch from the svn diff) and then commit them to your fork; you'd then initiate a pull request to us. This is the better option. And even though it sounds like a lot of work, It probably really is not. I can help you on irc if you run into problems (#hibernate-dev on freenode), or the folks on github irc (#guithub on freenode) can help too I am sure -- Steve Ebersole <steve(a)hibernate.org&gt; http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Be kind of stupid to not huh? ;) http://opensource.atlassian.com/projects/hibernate/browse/HHH-5632 On Friday, October 08, 2010 10:54:48 am Strong Liu wrote: > btw, any plan that merge the hibernate4 source to github? > > On Oct 8, 2010, at 9:36 PM, Steve Ebersole wrote: > > Hey Paul > > > > On Thursday, October 07, 2010 07:23:31 pm Paul Benedict wrote: > >> I missed the behind-the-scenes discussion. Why was SVN booted? > > > > We generally discuss stuff like this at our weekly dev meetings on irc. > > > >> And can > >> I still submit SVN diff patches? > > > > I personally do not know how to apply an SVN diff against Git. Or at > > least I have not tried to see if it will work (pretty sure patch can > > apply diffs produced by SVN). > > > > The other option you have is to move the work over to a GitHub fork of > > the main hibernate repo, reapply your changes (either copy them in > > place or using patch from the svn diff) and then commit them to your > > fork; you'd then initiate a pull request to us. This is the better > > option. And even though it sounds like a lot of work, It probably > > really is not. > > > > I can help you on irc if you run into problems (#hibernate-dev on > > > > freenode), or the folks on github irc (#guithub on freenode) can help > > too I am sure

btw, any plan that merge the hibernate4 source to github? On Oct 8, 2010, at 9:36 PM, Steve Ebersole wrote: > Hey Paul > > On Thursday, October 07, 2010 07:23:31 pm Paul Benedict wrote: >> I missed the behind-the-scenes discussion. Why was SVN booted? > > We generally discuss stuff like this at our weekly dev meetings on irc. > >> And can >> I still submit SVN diff patches? > > I personally do not know how to apply an SVN diff against Git.  Or at least I > have not tried to see if it will work (pretty sure patch can apply diffs > produced by SVN). > > The other option you have is to move the work over to a GitHub fork of the > main hibernate repo, reapply your changes (either copy them in place or using > patch from the svn diff) and then commit them to your fork; you'd then initiate > a pull request to us.  This is the better option.  And even though it sounds > like a lot of work, It probably really is not.  I can help you on irc if you > run into problems (#hibernate-dev on freenode), or the folks on github irc > (#guithub on freenode) can help too I am sure > > -- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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&gt; http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Git on purpose does not allow for partial checkout. Sorry. What you can do is do ashallow clone ie to get all the history. This does not solve your problem, simply speed things up --depth <depth> Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. On 8 oct. 2010, at 06:41, Strong Liu <stliu(a)hibernate.org&gt; wrote: > hello git gurus, > > here a question: > > how to perform a partial checkout? in our testsuite hudson job, we only > need the testsuite module, and the purpose for this job is testing the > artifacts that upstream core job deployed. of course check out the whole > project is an option, but this will force the testsuite job uses parent > module in the same checkout but the artifact in maven repo. any > suggestion? > > On Oct 8, 2010, at 5:20 AM, Steve Ebersole wrote: >> 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). > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

> 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).

From there, HHH-XXX should be an upstream of 3.5 and you can do