This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: git conversion in progress
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <gcc at gcc dot gnu dot org>
- Date: Sat, 11 Jan 2020 22:40:36 +0000
- Subject: Re: git conversion in progress
- Ironport-sdr: pwcuqDeL5YIVLaOhtN9ZVn4gcrfdYKezz6jVsqOcUadZuHqIE8+snKVen25Ffl7ZkT8SSZfGdu Bo4T98emhAxR89U+A7h1iId0RtMjfNfDyGcoVfpx/yGDsVfwD5Qo7yV7ATZINZaOGr0m7XQLmg 7T8+oCIX0xWG/qZncxA9bPOTWquit9eT80HL8yRhkwir13ZqgTHcAuuCeQKRDAXF6EK3YfqvEK LhImKBJGCAqupjlCgUxUh4lowFSBBwOwfLe9rBYj8KB0exCw4Oy/3IpD2bfUtguNteRq36rufy 5OA=
- Ironport-sdr: qAPT5ksEhxBRey85fm+2GfMMgWru7ubYymK6CuIGjoPpi2fbMrAK8aINebpvcpnKCvOdx8kuPB ylrenVp+lsSWTaTHEFI6osSEC0HZahastabdn1ABLpQ1XKIpMp3LpFJddoB1iJSvKI7OILFgGp RydxaiNTarop9w7trmB076IN3fp6LQyzvpq92bBa3kJQGzfr31C9rDDf72MMKy7aWajpWSBQ6x GyyhicSKSu+tfOu4lClmd3kdM31iy6zTIKSeQxG8aJvQfccEvnxMdD6Dk9cc/3krvEe9hZiDt7 N9A=
- References: <alpine.DEB.2.21.2001110102500.13991@digraph.polyomino.org.uk>
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