This is the mail archive of the
mailing list for the binutils project.
Re: A Proposal to Move to Git
- From: Tom Tromey <tromey at redhat dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb at sourceware dot org, binutils at sourceware dot org
- Date: Thu, 22 Aug 2013 15:10:45 -0600
- Subject: Re: A Proposal to Move to Git
- References: <8738q4gj7a dot fsf at fleche dot redhat dot com> <201308222010 dot r7MKAljG013904 at glazunov dot sibelius dot xs4all dot nl>
Mark> Except for one tiny question. How much free space do I need to clone
Mark> the future gdb repo and do useful work with it? Some of my machines
Mark> don't have a lot of free disk space. Sparse checkouts don't really
Mark> work. And it seems you can't do any real development from a shallow
Mark> clone. So if the answer to the my question is that I need at least 1G
Mark> of disk space, then there is a problem.
gdb.git is 372M. That's the bare repository, so no checkout. It may be
a bit bigger when we mix in binutils, though the final numbers will all
be different for a variety of reasons. I think 400M is an ok rough
I think you have several options here.
I believe you can push from a --single-branch clone. One of these
weighed in at 304M for me. That was a checkout, not a bare repository.
Note that a gdb+binutils checkout from CVS is 321M. So I think that,
whatever the issue is, it will be at the margin.
Alternatively, you can adopt a more laborious approach by doing a
shallow clone on a space-constrained device, and shipping the results to
a push-capable repository. I've done this at times (not due to space
but because I couldn't conveniently push from the machine I was hacking
Or, maybe you can run git-cvs locally and cvs commit from your space
constrained device into your git repository. I have never tried this.