Re: [hibernate-dev] Hibernate Core is now using Git
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> 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).
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> 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