This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Vendor branches on's binutils-gdb repo


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. 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:


(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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]