This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: git conversion in progress


On Sat, 11 Jan 2020, Joseph Myers wrote:

> the older test conversions 1 through 7).  Some cron jobs may be re-enabled 
> before then, subject to testing (I have git changes to gcc_release ready, 
> for example, for testing snapshot generation), but the DATESTAMP updates 
> won't be enabled until the repository is writable.

Snapshot generation is working (not yet enabled from cron).  I also have 
DATESTAMP updates working (tested with gcc-reposurgeon-8.git).  However, 
they seem to be much slower than expected.  The slow step is pushing a 
commit made locally to the gcc-reposurgeon-8.git repository; I see 
processes

gccadmin 121505  0.0  0.0 106080  1420 pts/2    S+   22:35   0:00      \_ /bin/sh ./update_version_git
gccadmin 121834  0.0  0.0 214308 52808 pts/2    Sl+  22:35   0:00          \_ git push origin master
gccadmin 121835  0.0  0.0 215396 54300 pts/2    Sl+  22:35   0:00              \_ git-receive-pack /home/gccadmin/gcc-reposurgeon-8.git
gccadmin 121839 99.3  0.8 1597152 613180 pts/2  R+   22:35   1:58              \_ git pack-objects --all-progress-implied --revs --stdout --thin --delta-base-offset --progress

and there should be no need for a time-consuming pack-objects step, the 
DATESTAMP update commit should never add more than four small new objects 
(one commit, two trees, one blob) and such a push when done from a git+ssh 
checkout runs very quickly.  Any advice on why pushing a trival commit 
locally (but not remotely) should be so slow?

-- 
Joseph S. Myers
joseph@codesourcery.com


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