[hibernate-dev] Hibernate Core is now using Git

[Steve Ebersole]

Bear in mind too though that the git clone operation is *much* faster than the 
corresponding svn checkout.  

Simply having all the modules "there" will not force Maven to do anything.  
Maven *always* uses the version of dependencies from the repo.  So unless you 
run install on the core module you just got, running the tests in testsuite 
will use the previously built one from the repo (or repo cache more likely 
here i guess).

On Friday, October 08, 2010 02:39:28 am Emmanuel Bernard wrote:
> 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 at hibernate.org> 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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org