Re: Git and GCC

["J.C. Pizarro" <jcpiza at gmail dot com>]

On 12/5/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc --aggressive --prune.  Two hours
> later, it finished.
> The final size after this is 1.5 gig for all of the history of gcc for
> just trunk.
>
> dberlin@home:/compilerstuff/gitgcc/gccrepo/.git/objects/pack$ ls -trl
> total 1568899
> -r--r--r-- 1 dberlin dberlin 1585972834 2007-12-05 14:01
> pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.pack
> -r--r--r-- 1 dberlin dberlin   19008488 2007-12-05 14:01
> pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.idx
>
> This is 3x bigger than hg *and* hg doesn't require me to waste my life
> repacking every so often.
> The hg operations run roughly as fast as the git ones
>
> I'm sure there are magic options, magic command lines, etc, i could
> use to make it smaller.
>
> I'm sure if i spent the next few weeks fucking around with git, it may
> even be usable!
>
> But given that git is harder to use, requires manual repacking to get
> any kind of sane space usage, and is 3x bigger anyway, i don't see any
> advantage to continuing to experiment with git and gcc.
>
> I already have two way sync with hg.
> Maybe someday when git is more usable than hg to a normal developer,
> or it at least is significantly smaller than hg, i'll look at it
> again.
> For now, it seems a net loss.
>
> --Dan
> >
> > git clone --depth 100 git://git.infradead.org/gcc.git
> >
> > should give around ~50mb repository with usable trunk. This is all thanks to
> > Bernardo Innocenti for setting up an up-to-date gcc git repo.
> >
> > P.S:Please cut down on the usage of exclamation mark.
> >
> > Regards,
> > ismail
> >
> > --
> > Never learn by your mistakes, if you do you may never dare to try again.
> >

To see "Re: svn trunk reaches nearly 1 GiB!!! That massive!!!"

http://gcc.gnu.org/ml/gcc/2007-11/msg00805.html
http://gcc.gnu.org/ml/gcc/2007-11/msg00770.html
http://gcc.gnu.org/ml/gcc/2007-11/msg00769.html
http://gcc.gnu.org/ml/gcc/2007-11/msg00768.html
http://gcc.gnu.org/ml/gcc/2007-11/msg00767.html

On 12/5/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc --aggressive --prune.  Two hours
> later, it finished.
> The final size after this is 1.5 gig for all of the history of gcc for
> just trunk.
>
> dberlin@home:/compilerstuff/gitgcc/gccrepo/.git/objects/pack$ ls -trl
> total 1568899
> -r--r--r-- 1 dberlin dberlin 1585972834 2007-12-05 14:01
> pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.pack
> -r--r--r-- 1 dberlin dberlin   19008488 2007-12-05 14:01
> pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.idx
>
> This is 3x bigger than hg *and* hg doesn't require me to waste my life
> repacking every so often.
> The hg operations run roughly as fast as the git ones
>
> I'm sure there are magic options, magic command lines, etc, i could
> use to make it smaller.
>
> I'm sure if i spent the next few weeks fucking around with git, it may
> even be usable!
>
> But given that git is harder to use, requires manual repacking to get
> any kind of sane space usage, and is 3x bigger anyway, i don't see any
> advantage to continuing to experiment with git and gcc.
>
> I already have two way sync with hg.
> Maybe someday when git is more usable than hg to a normal developer,
> or it at least is significantly smaller than hg, i'll look at it
> again.
> For now, it seems a net loss.
>
> --Dan
> >
> > git clone --depth 100 git://git.infradead.org/gcc.git
> >
> > should give around ~50mb repository with usable trunk. This is all thanks to
> > Bernardo Innocenti for setting up an up-to-date gcc git repo.
> >
> > P.S:Please cut down on the usage of exclamation mark.
> >
> > Regards,
> > ismail
> >
> > --
> > Never learn by your mistakes, if you do you may never dare to try again.
> >

To see "Re: svn trunk reaches nearly 1 GiB!!! That massive!!!"

http://gcc.gnu.org/ml/gcc/2007-11/msg00805.html
http://gcc.gnu.org/ml/gcc/2007-11/msg00770.html
http://gcc.gnu.org/ml/gcc/2007-11/msg00769.html
http://gcc.gnu.org/ml/gcc/2007-11/msg00768.html
http://gcc.gnu.org/ml/gcc/2007-11/msg00767.html

* In http://gcc.gnu.org/ml/gcc/2007-11/msg00675.html , i did put

The generated files from flex/bison are a lot of "trashing hexadecimals" that
don't must to be commited to any cvs/svn/git/hg because it consumes
a lot of diskspace for only a modification of few lines of flex/bison sources.

* In http://gcc.gnu.org/ml/gcc/2007-11/msg00683.html , i did put

I hate considering temporary files as sources of the tree. They aren't sources.

It's good idea to remove ALL generated files from sources:

A) generated *.c, *.h from lex/bison sources *.l/*.y
B) generated not-handwritten configure, makefile, aclocal.m4, config.h.in,
     makefile.in from the configure.ac and makefile.am sources.
      [the handwritten configure and makefile have to be rewritten to *.ac/*.am]
C) generated binary objects *.class, *.o, *.a, *.so, ...
D) generated *.c, *.h, *.cpp, *.hpp,  ... from *.java
E) any generated from any available source by available tool.

The only exception is when the project need a bootstrapping system.

See to understand http://en.wikipedia.org/wiki/GNU_build_system easy!

So, the cvs/svn/git/hg repositories of sources will be "small and clean"
without "trashing generated files, hexadecimals, ..."

This recommendation is an advantage to navigate by web to clean
cvs/svn/git/hg repositories. In another case, it's an inconvenient.

   J.C.Pizarro