This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Vendor branches on sourceware.org's binutils-gdb repo
- From: Michael Matz <matz at suse dot de>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: brobecker at adacore dot com, aaro dot koskinen at iki dot fi, sergiodj at redhat dot com, emachado at linux dot vnet dot ibm dot com, gdb at sourceware dot org, binutils at sourceware dot org, bergner at vnet dot ibm dot com, tuliom at linux dot vnet dot ibm dot com
- Date: Mon, 7 Apr 2014 17:41:43 +0200 (CEST)
- 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>
Hi,
On Mon, 7 Apr 2014, Mark Kettenis wrote:
> > But it's not necessarily easy for the vendor to _host_ that other
> > repository.
>
> Really? Are there really companies that are active in the Free Software
> community that don't have the infrastructure to host a relatively small
> git repo?
It's not the infrastructure. It's policies. Some companies have a policy
of not publishing any code outside except through a heavy process, which
might include a white-list of where it may be published/hosted.
sourceware.org is on that white-list already. It may be very painful to
extend that white-list.
> > And IMHO, the current 288 MB for binutils-gdb git objects aren't
> > enough to discourage vendor branches (and if you're worried about
> > the download size it's equally easy to simply not pull those
> > branches).
>
> Size is an issue for me. I try to support GDB on many platforms, some
> of which are somewhat old or low power and don't have a lot of disk
> storage. I'm already running into problems on some of my machines.
> And every time git messes up my repo because I run out of disk space
> (or just because it doesn't seem to properly implement DWIM) I need to
> fetch everything all over again.
>
> 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.
master only is easy:
git config remote.origin.fetch +refs/heads/master:refs/remotes/origin/master
By default that setting is "+refs/heads/*:refs/remotes/origin/*" which
fetches everything under refs/heads/ (recursively unfortunately).
Furthermore the above aren't really filename globs (so e.g.
refs/heads/[^v]* doesn't work), but you can have multiple such refspecs.
So to retrieve just a subset of branches you can name them all
individually (git-config --add), or we need to employ some namespace
scheme where nothing is directly in refs/heads/, but only in
subdirectories of that. Then we could have:
+refs/heads/default/*:refs/remotes/origin/default/*
+refs/heads/vendor/*:refs/remotes/origin/vendor/*
(Or further subsetted to only some vendors). I'll admit that naming
subsets of branches to fetch is not that "easy" without changes in the
repository structure.
Ciao,
Michael.