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 jos...@codesourcery.com
