If we merge (not rebase) then we should be fine to do it without everyone having to push first. So lets set a time for this to happen. I really want to hold off branching for JPA 2.1 implementation work until this happens, so the sooner the better. Tomorrow (6/5)?
Out of curiosity, why 2 merges? That brings up whether we use rebase to integrate metamodel back into master whenever we are ready. In my experience (based on pull requests with merges of master) the rebase is really smart about weeding out merge commits. Or do we just live with the merge commits on the main code line? Also, we should discuss branching 4.1 and moving metamodel to master. I think that is really the situation we have now (only bug fixes on master, feature dev on metamodel). On Tue 05 Jun 2012 09:17:06 AM CDT, John Verhaeg wrote: > +1 for early merges and Hardy's suggestion to merge first w/o combining test& > matrix, then again after combining. > > On Jun 5, 2012, at 9:11 AM, Hardy Ferentschik wrote: > >> >> On Jun 5, 2012, at 3:56 PM, Steve Ebersole wrote: >> >>> Would we merge the directories on each branch and then merge branches? >>> From what little I know of git I think this would be best. >> >> What's about doing first a merge keeping test and matrix and then combining >> test+matrix on master and do another merge/rebase? >> >> >> >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > JPAV > > > > -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
