From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9c545c7fbde6ddecb82def2dc66194ed@lilly.quanstro.net> References: <385c85ca703ac8d441c4227d1bb24643@u2.inri> <9c545c7fbde6ddecb82def2dc66194ed@lilly.quanstro.net> Date: Sat, 10 Oct 2015 20:25:50 +0200 Message-ID: From: =?UTF-8?Q?=C3=81lvaro_Jurado?= To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e01182d96d0e0330521c439bf Subject: Re: [9fans] off topic - a good Git reference Topicbox-Message-UUID: 72424592-ead9-11e9-9d60-3106f5b1d025 --089e01182d96d0e0330521c439bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree at all. As I said, after some time fighting with it I was bored. I remember asking you in g+ about fsync issues when I was working on it. In fact it fails for example, if you clone go repo and then checkout a branch. While checking out it looses in any moment some sha key and then fatal. Other times not. I used an ape libs compiled with gcc and gnu toolchain port, but that means one can use normal ape to have working. Libs are the same. Inside, it's hellish. Full of redundant code and configure "tool" does not make all the work. You will need to tweak adding things in conf file generated. It uses many shell scripts and it's designed to have many symlinks to git binary, what does you have many git clones with different names unless you hack install part of the makefile. If it doesn't detect a working ln, it does a cp. I never got 2.x versions working, sha key mess was changed after 2.0. About fsync, I'm not a fan, I wasn't blaming plan9 in anyway. It can go jump to a lake. =C3=81lvaro El 10/10/2015 17:27, "erik quanstrom" escribi=C3=B3= : > > It works with go get but sometimes it fails miserably retrieving packag= es > > because it has an strong dependency of fsync to freeze sha keys in fs > > during fetching. And that is just a dummy in Plan 9 ape. I used fflush > > i believe the problem has been misdiagnosed. fsync can't be the issue, > since there are no such buffers on plan 9. > > - erik > > --089e01182d96d0e0330521c439bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Agree at all. As I said, after some time fighting with it I = was bored. I remember asking you in g+ about fsync issues when I was workin= g on it.

In fact it fails for example, if you clone go repo and then = checkout a branch. While checking out it looses in any moment some sha key = and then fatal. Other times not.

I used an ape libs compiled with gcc and gnu toolchain port,= but that means one can use normal ape to have working. Libs are the same.<= /p>

Inside, it's hellish. Full of redundant code and configu= re "tool" does not make all the work. You will need to tweak addi= ng things in conf file generated. It uses many shell scripts and it's d= esigned to have many symlinks to git binary, what does you have many git cl= ones with different names unless you hack install part of the makefile. If = it doesn't detect a working ln, it does a cp.

I never got 2.x versions working, sha key mess was changed a= fter 2.0.

About fsync, I'm not a fan, I wasn't blaming plan9 i= n anyway. It can go jump to a lake.

=C3=81lvaro

El 10/10/2015 17:27, "erik quanstrom" = <quanstro@quanstro.net> = escribi=C3=B3:
> = It works with go get but sometimes it fails miserably retrieving packages > because it has an strong dependency of fsync to freeze sha keys in fs<= br> > during fetching. And that is just a dummy in Plan 9 ape. I used fflush=

i believe the problem has been misdiagnosed.=C2=A0 fsync can't be the i= ssue,
since there are no such buffers on plan 9.

- erik

--089e01182d96d0e0330521c439bf--