public inbox for
 help / color / mirror / Atom feed
From: Mark Wielaard <>
To: Overseers mailing list <>
Cc: Joseph Myers <>
Subject: Re: GNU Toolchain Infrastructure at sourceware
Date: Wed, 01 Jun 2022 12:09:44 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Joseph,

On Tue, 2022-05-31 at 22:12 +0000, Joseph Myers via Overseers wrote:
> On Tue, 31 May 2022, Mark Wielaard via Overseers wrote:
> > A more general point is that gcc.git is really a couple of orders
> > bigger than anything else. And that affects more things than just the
> > buildbot. I wonder if we should cut off a bit more history. It would
> > mean that people who really have to search back to before say gcc-5
> > need to stich in the gcc-old.git. But if it makes the default clone
> > 1GB smaller that would be really good.
> gcc-old.git is the old git-svn mirror, now read only.  It has no relation 
> to the main version of the history in gcc.git (the gcc-old.git history is 
> also available in gcc.git under refs/git-old/ and refs/git-svn-old/, not 
> fetched by default).

How embarrassing. I only assumed, I didn't actually check, (nor did I
actually try to create such a "small" gcc.git). You are of course
right. a) The default fetches objects go all the way back to including
pre egcs history. b) By default you indeed only fetch about 1GB.

> The vast bulk of the approximately 6000 refs in gcc.git are *not* fetched 
> by default, and the repository is set up with delta islands to make that 
> efficient.
> People not wanting full history of the branches they clone can create a 
> shallow clone with git clone --depth (and people wanting full history but 
> only for one branch can use --single-branch).
> The GCC repository size is similar to that for the Linux kernel.

Right, so it isn't completely unusual to have such large repos. And
indeed the buildbot workers do use --depth 1. So for automation this
isn't really such a big deal.

But I would say that like the linux kernel tree it is somewhat unusual
for developers to have such a giant tree. That 1GB is still somewhat
big on slower networks and it does take significant resources when
resolving the deltas.

--single-branch doesn't really significantly reduce that. But --depth 1
does of course. IMHO it would be good to have something in between.
Maybe a standard tree of --depth ~20000 (around when we cutover to
git). But maybe that is still too little history as a default. And it
could of course be clearly documented. But who reads docs...

Another hurdle for the first time gcc hacker is the default configure
flags. If you forget --disable-bootstrap for your first hacking it
really takes forever to build.

But maybe this is a better conversation on the gcc@ mailinglist. I also
may be too eager to be popular with hackers who don't like reading
setup documentation. And in the end gcc does contain so many frontends
and libraries these days that a single "easy" default is impossible to



  reply	other threads:[~2022-06-01 10:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-30 22:01 Mark Wielaard
2022-05-31 16:39 ` Frank Ch. Eigler
2022-05-31 21:50   ` Mark Wielaard
2022-05-31 22:12     ` Joseph Myers
2022-06-01 10:09       ` Mark Wielaard [this message]
2022-07-22 16:48   ` Mark Wielaard
2022-06-22  9:14 ` Roadmap update Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).