This is the mail archive of the
mailing list for the binutils project.
RE: Vendor branches on sourceware.org's binutils-gdb repo
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Andreas Schwab <schwab at suse dot de>, Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: "matz at suse dot de" <matz at suse dot de>, "brobecker at adacore dot com" <brobecker at adacore dot com>, "aaro dot koskinen at iki dot fi" <aaro dot koskinen at iki dot fi>, "sergiodj at redhat dot com" <sergiodj at redhat dot com>, "emachado at linux dot vnet dot ibm dot com" <emachado at linux dot vnet dot ibm dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>, "binutils at sourceware dot org" <binutils at sourceware dot org>, "bergner at vnet dot ibm dot com" <bergner at vnet dot ibm dot com>, "tuliom at linux dot vnet dot ibm dot com" <tuliom at linux dot vnet dot ibm dot com>
- Date: Mon, 7 Apr 2014 15:16:47 +0000
- Subject: RE: Vendor branches on sourceware.org's binutils-gdb repo
- Authentication-results: sourceware.org; auth=none
- References: <53406399 dot 9050303 at linux dot vnet dot ibm dot com> <m3vbunyoza dot fsf at redhat dot com> <20140406191404 dot GC7558 at drone dot musicnaut dot iki dot fi> <20140407035120 dot GA4186 at adacore dot com> <alpine dot LNX dot 2 dot 00 dot 1404071623060 dot 23408 at wotan dot suse dot de> <201404071452 dot s37EqLB9024528 at glazunov dot sibelius dot xs4all dot nl> <mvmsipp5gdb dot fsf at hawking dot suse dot de>
> > So how do I tell git to only clone master and not give me everybody
> > else's shit? Last time I tried to do that, it simply didn't work.
> Clone only the history leading to the tip of a single branch,
> either specified by the --branch option or the primary branch
> remoteâs HEAD points at.
If space is a problem and the purpose of the clone is mainly to perform a
build then you may also be interested in --depth. It comes with a health
warning but really reduces the overheads if it is suitable for you:
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.