Re: [9fans] off topic - a good Git reference

Re: [9fans] off topic - a good Git reference

[sl]

> My new employer uses svn but is about to migrate to git so I would
> be interested in a port, I might even get some cycles to help.

I'm no help here, but one of the Harvey guys (pre-Harvey) apparently
built git for Plan 9. Unfortunately, only the 386 binaries were made
available, no source code. I think this may just be because the
repository I found was not the source repository. Anyway:

	http://marcus.biz.tm/hg/gnubin

The git binary seems to run. I'm not sure if it works.

sl

Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Source should be in the same site, just add /files to hostname and look for
tgz. I think 1.5.8.3, last year version.

It was built with gcc 4.8 port for plan9 (static). You'll need some kind of
ksh to use it, git has many shell scripts.
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
during fetching. And that is just a dummy in Plan 9 ape. I used fflush
trying to make some tweak and disabling one sha check (it does 4 or 5) to
bypass that symptom, but finally I was bored at the end.

I still use it to go get, but it needs a deeply review and an upgrade.

Álvaro
El 07/10/2015 04:37, <sl@9front.org> escribió:

> > My new employer uses svn but is about to migrate to git so I would
> > be interested in a port, I might even get some cycles to help.
>
> I'm no help here, but one of the Harvey guys (pre-Harvey) apparently
> built git for Plan 9. Unfortunately, only the 386 binaries were made
> available, no source code. I think this may just be because the
> repository I found was not the source repository. Anyway:
>
>         http://marcus.biz.tm/hg/gnubin
>
> The git binary seems to run. I'm not sure if it works.
>
> sl
>
>

[-- Attachment #2: Type: text/html, Size: 1664 bytes --]

Re: [9fans] off topic - a good Git reference

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On 7 October 2015 at 16:17, Álvaro Jurado <elbingmiss@gmail.com> wrote:

> 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


fsync causes any operating system buffers in the "buffer cache" to be
flushed to "disk" (not user-space buffers), so nothing should be needed
with plan 9, which is why fsync is a nop in APE.

[-- Attachment #2: Type: text/html, Size: 707 bytes --]

Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

Yes, it has no sense in Plan 9, I know, thanks. I was talking about ape lib
because is what was used to port git in my case.

I even found a Rob's old mail answering a similar question saying that it's
a matter of file server (I can't remember original question). And there are
many debates around internet about fsync, with fans an detractors.

In previous versions of git, there weren't fsyncs to freeze keys, but Linus
wanted to change old git behaviour at one moment, 1.8 version I think. And
after all, problem is still there in this case, there's no way to ensure if
an fd is in the heaven of bits or in any place in fs at the moment of fopen
issue by git, breaking its behaviour over Plan 9.

Álvaro
El 07/10/2015 18:26, "Charles Forsyth" <charles.forsyth@gmail.com> escribió:

>
> On 7 October 2015 at 16:17, Álvaro Jurado <elbingmiss@gmail.com> wrote:
>
>> 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
>
>
> fsync causes any operating system buffers in the "buffer cache" to be
> flushed to "disk" (not user-space buffers), so nothing should be needed
> with plan 9, which is why fsync is a nop in APE.
>

[-- Attachment #2: Type: text/html, Size: 1815 bytes --]

Re: [9fans] off topic - a good Git reference

[erik quanstrom]

On Wed Oct  7 14:25:58 PDT 2015, elbingmiss@gmail.com wrote:

> Yes, it has no sense in Plan 9, I know, thanks. I was talking about ape lib
> because is what was used to port git in my case.
>
> I even found a Rob's old mail answering a similar question saying that it's
> a matter of file server (I can't remember original question). And there are
> many debates around internet about fsync, with fans an detractors.
>
> In previous versions of git, there weren't fsyncs to freeze keys, but Linus
> wanted to change old git behaviour at one moment, 1.8 version I think. And
> after all, problem is still there in this case, there's no way to ensure if
> an fd is in the heaven of bits or in any place in fs at the moment of fopen
> issue by git, breaking its behaviour over Plan 9.

so we have these facts
1.  git worked without the fsync,
2.  on plan 9, fsync is unnecessary

yet, the agument is: because ape fsync, git is broken on plan 9?

i'm afraid i don't understand this reasoning.

also, directly to the "heaven of bits".  i assume you mean the data in the
file to which the fd points.  all unix-like systems provide some consistency
guarantees.  if a file is manipulated by a single program on a single machine,
there will always be a strongly coherent view of the file.

perhaps there is some confusion between the system call interface, which
uses file desciptors and stdio, which does do read and write buffering?  fsync
doesn't take care of that, either.

in the case of system crash, fsync doesn't provide strong guarantees that the
write will not be lost, or the fs not corrupted even in linux.  some versions of
the linux kernel do nothing on fsync, fsync doesn't actually put data on disk
https://lwn.net/Articles/270891/ and some options for ext make fsyncs
useless https://lwn.net/Articles/328363/

- erik

Re: [9fans] off topic - a good Git reference

[Steffen Nurpmeso]

erik quanstrom <quanstro@quanstro.net> wrote:
 |On Wed Oct  7 14:25:58 PDT 2015, elbingmiss@gmail.com wrote:
 |in the case of system crash, fsync doesn't provide strong \
 |guarantees that the
 |write will not be lost, or the fs not corrupted even in li\
 |nux.  some versions of
 |the linux kernel do nothing on fsync, fsync doesn't actual\

Linux fsync(2) says that the file itself is fine after it, but for
the filesystem metadata you need an additional fsync(2) on the
directory the file resides in.
The final wording of the related POSIX issue[1] states that the
latter is only necessary if directory entries have been created or
removed (also regarding rename(2) which needs two fsync(2) calls;
luckily we're binary only), and noone has opposed to this wording
in more than two years.
(Mac OS X Snow Leopard had a F_FULLFSYNC fcntl(2) which provided
the fully-synced guarantee, as in
        _os_fsync = os.fsync
        def __fullfsync(fd):
            if not SAFE_FSYNC:
                return _os_fsync(fd)
            try:
                fcntl.fcntl(fd, fcntl.F_FULLFSYNC)
            except IOError as e:
                if e.errno == errno.ENOTTY:
                    return _os_fsync(fd)
                raise
        os.fsync = __fullfsync
which i thought of as a good idea, from a programmers point of
view who wants to get it done.)

  [1] http://austingroupbugs.net/view.php?id=672#c1618

--steffen

Re: [9fans] off topic - a good Git reference

[erik quanstrom]

> 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
> 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

Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

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.

Álvaro
El 10/10/2015 17:27, "erik quanstrom" <quanstro@quanstro.net> escribió:

> > 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
> > 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
>
>

[-- Attachment #2: Type: text/html, Size: 1864 bytes --]

Re: [9fans] off topic - a good Git reference

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

On 10 October 2015 at 19:25, Álvaro Jurado <elbingmiss@gmail.com> wrote:

> While checking out it looses in any moment some sha key and then fatal.
> Other times not.


Why do  you think that was fsync, and not something else?

[-- Attachment #2: Type: text/html, Size: 553 bytes --]

Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

I remember tracing entire clone process. It was hanging in a function
(don't remember which, the only one has fsync) what ensures sha key is in
fs. I bypassed it with a rare mess, so if key is there, it works, if not,
fails. In fact fsync changes introduced by Linus was in the line of
ensuring that key is there to decompress package.
Maybe I was wrong. When I'll back to port git for Harvey, I'll see.

Álvaro
El 12/10/2015 13:49, "Charles Forsyth" <charles.forsyth@gmail.com> escribió:

>
> On 10 October 2015 at 19:25, Álvaro Jurado <elbingmiss@gmail.com> wrote:
>
>> While checking out it looses in any moment some sha key and then fatal.
>> Other times not.
>
>
> Why do  you think that was fsync, and not something else?
>
>

[-- Attachment #2: Type: text/html, Size: 1329 bytes --]

Re: [9fans] off topic - a good Git reference

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On 12 October 2015 at 17:49, Álvaro Jurado <elbingmiss@gmail.com> wrote:

> what ensures sha key is in fs.


The reason many of us are a little sceptical about it being fsync as such
preventing the data appearing
is that if the git function that writes the key does a write or pwrite,
the key will be in the file system on Plan 9: there's no need for an fsync
just to get it there.
In fact, in Linux there's no need for an fsync just to get it there: it
only matters in the case of a crash.

If the file system fails or you reset the machine, the intention of the
fsync will be frustrated, but
it shouldn't affect normal operation where no file server crash occurs.

As it happens, a wstat that changes nothing can be interpreted by a file
server to have a similar effect as fsync (see stat(5)).

[-- Attachment #2: Type: text/html, Size: 1348 bytes --]

Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

Has sense. Thanks Charles.

Álvaro
El 12/10/2015 19:03, "Charles Forsyth" <charles.forsyth@gmail.com> escribió:

>
> On 12 October 2015 at 17:49, Álvaro Jurado <elbingmiss@gmail.com> wrote:
>
>> what ensures sha key is in fs.
>
>
> The reason many of us are a little sceptical about it being fsync as such
> preventing the data appearing
> is that if the git function that writes the key does a write or pwrite,
> the key will be in the file system on Plan 9: there's no need for an fsync
> just to get it there.
> In fact, in Linux there's no need for an fsync just to get it there: it
> only matters in the case of a crash.
>
> If the file system fails or you reset the machine, the intention of the
> fsync will be frustrated, but
> it shouldn't affect normal operation where no file server crash occurs.
>
> As it happens, a wstat that changes nothing can be interpreted by a file
> server to have a similar effect as fsync (see stat(5)).
>

[-- Attachment #2: Type: text/html, Size: 1730 bytes --]

Re: [9fans] off topic - a good Git reference

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

2015-10-12 19:00 GMT+02:00 Charles Forsyth <charles.forsyth@gmail.com>:

>
> On 12 October 2015 at 17:49, Álvaro Jurado <elbingmiss@gmail.com> wrote:
>
>> what ensures sha key is in fs.
>
>
> The reason many of us are a little sceptical about it being fsync as such
> preventing the data appearing
> is that if the git function that writes the key does a write or pwrite,
> the key will be in the file system on Plan 9: there's no need for an fsync
> just to get it there.
> In fact, in Linux there's no need for an fsync just to get it there: it
> only matters in the case of a crash.
>
> If the file system fails or you reset the machine, the intention of the
> fsync will be frustrated, but
> it shouldn't affect normal operation where no file server crash occurs.
>
> As it happens, a wstat that changes nothing can be interpreted by a file
> server to have a similar effect as fsync (see stat(5)).
>

Thus Plan9 HAS fsync! :-o
And it also has server-defined semantics! Very impressive!


Giacomo

[-- Attachment #2: Type: text/html, Size: 2021 bytes --]

Re: [9fans] off topic - a good Git reference

[erik quanstrom]

[-- Attachment #1: Type: text/html, Size: 1218 bytes --]

Re: [9fans] off topic - a good Git reference

[Andrew Simmons]

Well, colour me confused. I  can make no sense of this thread. Would that Boyd were here to explain it.

> On Oct 3, 2015, at 5:48 pm, erik quanstrom <quanstro@quanstro.net> wrote:
> 
> did you fix the SSL interface in python, too? 
> 
> - erik
> On Oct 2, 2015 9:37 PM, Nick Owens <mischief@offblast.org> wrote:
> 9front now supports tls 1.2 in libsec/devtls. Mercurial can make use of it through webfs.
> 
> On Oct 2, 2015 7:35 PM, "erik quanstrom" <quanstro@quanstro.net> wrote:
> On Fri Oct  2 18:46:06 PDT 2015, khm@sciops.net wrote:
> > On Fri, Oct 02, 2015 at 11:56:47PM +0200, a.regenfuss@gmx.de wrote:
> > > >Mercurial works.
> > > If you have got an installed python.
> >
> > that's pretty much universally the case for mercurial, yes.
> 
> well, there are some problems with ssl.
> 
> - erik
> 

Re: [9fans] off topic - a good Git reference

[Jacob Todd]

[-- Attachment #1: Type: text/plain, Size: 80 bytes --]

you can use mercurial on plan 9 with python installed, not hard to
understand

[-- Attachment #2: Type: text/html, Size: 96 bytes --]

Re: [9fans] off topic - a good Git reference

[Jeff Sickel]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

Not unless they forked the fork and fixed the ssl module in the Python 2.7.9-plan9 branch.

I’ve not had the time nor energy to finish it off yet.

-jas

> On Oct 2, 2015, at 11:48 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> 
> did you fix the SSL interface in python, too? 
> 
> - erik
> On Oct 2, 2015 9:37 PM, Nick Owens <mischief@offblast.org> wrote:
> 9front now supports tls 1.2 in libsec/devtls. Mercurial can make use of it through webfs.
> 
> On Oct 2, 2015 7:35 PM, "erik quanstrom" <quanstro@quanstro.net <mailto:quanstro@quanstro.net>> wrote:
> On Fri Oct  2 18:46:06 PDT 2015, khm@sciops.net <mailto:khm@sciops.net> wrote:
> > On Fri, Oct 02, 2015 at 11:56:47PM +0200, a.regenfuss@gmx.de <mailto:a.regenfuss@gmx.de> wrote:
> > > >Mercurial works.
> > > If you have got an installed python.
> >
> > that's pretty much universally the case for mercurial, yes.
> 
> well, there are some problems with ssl.
> 
> - erik
> 


[-- Attachment #2: Type: text/html, Size: 2179 bytes --]

Re: [9fans] off topic - a good Git reference

[Jacob Todd]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

that's all we use on 9front, though they might be using a different version.
On Oct 3, 2015 3:29 PM, "Jeff Sickel" <jas@corpus-callosum.com> wrote:

> Not unless they forked the fork and fixed the ssl module in the Python
> 2.7.9-plan9 branch.
>
> I’ve not had the time nor energy to finish it off yet.
>
> -jas
>
> On Oct 2, 2015, at 11:48 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>
> did you fix the SSL interface in python, too?
>
> - erik
> On Oct 2, 2015 9:37 PM, Nick Owens <mischief@offblast.org> wrote:
>
> 9front now supports tls 1.2 in libsec/devtls. Mercurial can make use of it
> through webfs.
> On Oct 2, 2015 7:35 PM, "erik quanstrom" <quanstro@quanstro.net> wrote:
>
> On Fri Oct  2 18:46:06 PDT 2015, khm@sciops.net wrote:
> > On Fri, Oct 02, 2015 at 11:56:47PM +0200, a.regenfuss@gmx.de wrote:
> > > >Mercurial works.
> > > If you have got an installed python.
> >
> > that's pretty much universally the case for mercurial, yes.
>
> well, there are some problems with ssl.
>
> - erik
>
>
>

[-- Attachment #2: Type: text/html, Size: 2113 bytes --]

Re: [9fans] off topic - a good Git reference

[Prof Brucee]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Just buy a tshirt.
On 04/10/2015 6:59 AM, "Jacob Todd" <jaketodd422@gmail.com> wrote:

> that's all we use on 9front, though they might be using a different
> version.
> On Oct 3, 2015 3:29 PM, "Jeff Sickel" <jas@corpus-callosum.com> wrote:
>
>> Not unless they forked the fork and fixed the ssl module in the Python
>> 2.7.9-plan9 branch.
>>
>> I’ve not had the time nor energy to finish it off yet.
>>
>> -jas
>>
>> On Oct 2, 2015, at 11:48 PM, erik quanstrom <quanstro@quanstro.net>
>> wrote:
>>
>> did you fix the SSL interface in python, too?
>>
>> - erik
>> On Oct 2, 2015 9:37 PM, Nick Owens <mischief@offblast.org> wrote:
>>
>> 9front now supports tls 1.2 in libsec/devtls. Mercurial can make use of
>> it through webfs.
>> On Oct 2, 2015 7:35 PM, "erik quanstrom" <quanstro@quanstro.net> wrote:
>>
>> On Fri Oct  2 18:46:06 PDT 2015, khm@sciops.net wrote:
>> > On Fri, Oct 02, 2015 at 11:56:47PM +0200, a.regenfuss@gmx.de wrote:
>> > > >Mercurial works.
>> > > If you have got an installed python.
>> >
>> > that's pretty much universally the case for mercurial, yes.
>>
>> well, there are some problems with ssl.
>>
>> - erik
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 2462 bytes --]

[9fans] off topic - a good Git reference

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 149 bytes --]

it is informative. i find it easy to read -- good flow and visually
pleasing typesetting.

http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

[-- Attachment #2: Type: text/html, Size: 278 bytes --]

Re: [9fans] off topic - a good Git reference

[Tiago Natel]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

is there someone else interested in write a git tool for plan 9 ?

[]'s

2015-09-29 13:58 GMT-03:00 Skip Tavakkolian <skip.tavakkolian@gmail.com>:

> it is informative. i find it easy to read -- good flow and visually
> pleasing typesetting.
>
> http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
>
>

[-- Attachment #2: Type: text/html, Size: 775 bytes --]

Re: [9fans] off topic - a good Git reference

[Kurt H Maier]

On Tue, Sep 29, 2015 at 02:18:20PM -0300, Tiago Natel wrote:
> is there someone else interested in write a git tool for plan 9 ?
>
> []'s

This has been written.  You just need to fill out a Secret Plan 9 Super
Secret Society application and find three Bilderbergs to vouch for you.

khm

Re: [9fans] off topic - a good Git reference

[erik quanstrom]

On Tue Sep 29 12:45:25 PDT 2015, khm@sciops.net wrote:
> On Tue, Sep 29, 2015 at 02:18:20PM -0300, Tiago Natel wrote:
> > is there someone else interested in write a git tool for plan 9 ?
> >
> > []'s
>
> This has been written.  You just need to fill out a Secret Plan 9 Super
> Secret Society application and find three Bilderbergs to vouch for you.

it's the super secret plan 9 society here!  we *hate* the sp9sss.

to the original question: i haven't used git on plan 9.  sorry, i don't have
any useful info.

- erik

Re: [9fans] off topic - a good Git reference

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 278 bytes --]

On 30 September 2015 at 04:11, erik quanstrom <quanstro@quanstro.net> wrote:

> > > is there someone else interested in write a git tool for plan 9 ?


it would be useful, to access git repositories directly. unfortunately, git
is a C program, so it's not very portable.

[-- Attachment #2: Type: text/html, Size: 573 bytes --]

Re: [9fans] off topic - a good Git reference

[hiro]

There isn't so much quality software that can be compiled directly on
plan9 and which is accessible only via git. Most useful stuff for
9front is in mercurial repos or even directly mountable via 9p.
Still a gitfs would be a fun project for someone who wants to play
with programming a simple example file server or so.
Why do you say C programs aren't portable, we have a C compiler already?

Re: [9fans] off topic - a good Git reference

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

On 30 September 2015 at 08:36, hiro <23hiro@gmail.com> wrote:

> Why do you say C programs aren't portable, we have a C compiler already?


I was being sarcastic about the portability of so much contemporary C code.
You can't just compile it, even in an an ANSI/POSIX environment.

[-- Attachment #2: Type: text/html, Size: 606 bytes --]

Re: [9fans] off topic - a good Git reference

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On 30 September 2015 at 08:47, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> I was being sarcastic about the portability of so much contemporary C code.


Here's a small but representative example.

#if HAVE_SYS_TIME_H
#include <sys/time.h
#elif HAVE_TIME_H
#include <time.h>
#endif

#if HAVE_SYS_CLOCK_GETTIME
time_t
time_now(void)
{
  struct timespec timespec_value;
  (void) clock_gettime(CLOCK_REALTIME, &timespec_value);
  return timespec_value.tv_seconds;
}
#elif HAVE_SYS_GETTIMEOFDAY
time_t
time_now(void)
{
  struct timeval timeval_value;
  (void) gettimeofday(&timeval_value, (struct timezone *) NULL);
  return timeval_value.tv_seconds;
}
#elif HAVE_SYS_TIME
time_t
time_now(void)
{
  time_t seconds_since_epoch;
  (void) time(&seconds_since_epoch);
  return seconds_since_epoch;
}
#endif

./configure    # work out which HAVE_... definitions to use

Usually there are a few more alternatives enumerated.  Surprisingly often,
the microseconds or nanoseconds
value is discarded, to get the seconds. You could just use #include
<time.h> and call time(NULL) to get that, but where's the fun?

[-- Attachment #2: Type: text/html, Size: 2476 bytes --]

Re: [9fans] off topic - a good Git reference

[Jeff Sickel]

> On Sep 30, 2015, at 2:59 AM, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> 
> Here's a small but representative example.

That’s just an example of a C file.  The joy of Git is the rest of the requirements to actually use it:

- bash
- perl5

And then if you want all the fancy tools & wrappers groups seem to like these days:

- python
- java
- php

And finally, a browser or other gui front end to make sense of it all.

Free software isn’t so free after all.

-jas

Re: [9fans] off topic - a good Git reference

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On 1 October 2015 at 18:31, Jeff Sickel <jas@corpus-callosum.com> wrote:

> > On Sep 30, 2015, at 2:59 AM, Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
> >
> > Here's a small but representative example.
>
> That’s just an example of a C file.


I was really just writing about the difficulty of current C portability in
general.
I hadn't looked at the Git source code in ages.

[-- Attachment #2: Type: text/html, Size: 851 bytes --]

Re: [9fans] off topic - a good Git reference

[Ryan Gonzalez]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

It's still free. It just takes a heck of a lot of effort to port it to
other platforms after you get addicted to it.

On Thu, Oct 1, 2015 at 12:31 PM, Jeff Sickel <jas@corpus-callosum.com>
wrote:

>
> > On Sep 30, 2015, at 2:59 AM, Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
> >
> > Here's a small but representative example.
>
> That’s just an example of a C file.  The joy of Git is the rest of the
> requirements to actually use it:
>
> - bash
> - perl5
>
> And then if you want all the fancy tools & wrappers groups seem to like
> these days:
>
> - python
> - java
> - php
>
> And finally, a browser or other gui front end to make sense of it all.
>
> Free software isn’t so free after all.
>
> -jas
>
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/

[-- Attachment #2: Type: text/html, Size: 1671 bytes --]

Re: [9fans] off topic - a good Git reference

[arnold]

Jeff Sickel <jas@corpus-callosum.com> wrote:

> And then if you want all the fancy tools & wrappers groups seem to like
> these days:

Git is best used from the command line. All the tools just get
in the way.

The libgit work is probably the way to go for Plan 9.

Arnold

Re: [9fans] off topic - a good Git reference

[hiro]

Is the git protocol really so huge that a native implementation
wouldn't be feasible?

Re: [9fans] off topic - a good Git reference

[Aram Hăvărneanu]

On Fri, Oct 2, 2015 at 10:32 AM, hiro <23hiro@gmail.com> wrote:
> Is the git protocol really so huge that a native implementation
> wouldn't be feasible?

The git protocol and file format is very simple. I'm sure it's easier
to write something from scratch than port git.

-- 
Aram Hăvărneanu

Re: [9fans] off topic - a good Git reference

[Joseph Stewart]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

Here's git "rewritten" in Javascript:

http://gitlet.maryrosecook.com/

-joe


On Fri, Oct 2, 2015 at 4:57 AM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:

> On Fri, Oct 2, 2015 at 10:32 AM, hiro <23hiro@gmail.com> wrote:
> > Is the git protocol really so huge that a native implementation
> > wouldn't be feasible?
>
> The git protocol and file format is very simple. I'm sure it's easier
> to write something from scratch than port git.
>
> --
> Aram Hăvărneanu
>
>

[-- Attachment #2: Type: text/html, Size: 1053 bytes --]

Re: [9fans] off topic - a good Git reference

[a.regenfuss]

>> Is the git protocol really so huge that a native implementation
>> wouldn't be feasible?

>The git protocol and file format is very simple. I'm sure it's easier
>to write something from scratch than port git.
>Aram Hăvărneanu

Is there a version control system that can be installed on Plan 9 without having to sacrifice a virgin?
I mean, venti is great, but having something similar to git or mercurial (or even svn/cvs...) would be nice.

adrian

Re: [9fans] off topic - a good Git reference

[Aram Hăvărneanu]

Mercurial works.

-- 
Aram Hăvărneanu

Re: [9fans] off topic - a good Git reference

[a.regenfuss]

>Mercurial works.
If you have got an installed python.
adrian

Re: [9fans] off topic - a good Git reference

[Kurt H Maier]

On Fri, Oct 02, 2015 at 11:56:47PM +0200, a.regenfuss@gmx.de wrote:
> >Mercurial works.
> If you have got an installed python.

that's pretty much universally the case for mercurial, yes.

khm

Re: [9fans] off topic - a good Git reference

[erik quanstrom]

On Fri Oct  2 18:46:06 PDT 2015, khm@sciops.net wrote:
> On Fri, Oct 02, 2015 at 11:56:47PM +0200, a.regenfuss@gmx.de wrote:
> > >Mercurial works.
> > If you have got an installed python.
>
> that's pretty much universally the case for mercurial, yes.

well, there are some problems with ssl.

- erik

Re: [9fans] off topic - a good Git reference

[Nick Owens]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

9front now supports tls 1.2 in libsec/devtls. Mercurial can make use of it
through webfs.
On Oct 2, 2015 7:35 PM, "erik quanstrom" <quanstro@quanstro.net> wrote:

> On Fri Oct  2 18:46:06 PDT 2015, khm@sciops.net wrote:
> > On Fri, Oct 02, 2015 at 11:56:47PM +0200, a.regenfuss@gmx.de wrote:
> > > >Mercurial works.
> > > If you have got an installed python.
> >
> > that's pretty much universally the case for mercurial, yes.
>
> well, there are some problems with ssl.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 871 bytes --]

Re: [9fans] off topic - a good Git reference

[lucio]

> having something similar to git or mercurial (or even svn/cvs...) would be nice.

CVS works adequately.  It's on sources and needs some minute fixes to
get the permissions exactly right: I kept getting files created with
exactly NO permission bits - my last disk failure got rid of my poor
efforts to fix that, so I can't even offer some bad advice.

Lucio.

Re: [9fans] off topic - a good Git reference

[a.regenfuss]

>CVS works adequately.
Thanks a lot.

adrian

Re: [9fans] off topic - a good Git reference

[Steve Simon]

In a previous job I put in some quite serious effort to
port SVN to APE, but it is dependent on... well pretty
much everything. I never managed to even get it to compile,
and lost the will to live.

My new employer uses svn but is about to migrate to git so I would
be interested in a port, I might even get some cycles to help.

-Steve

Re: [9fans] off topic - a good Git reference

[Steffen Nurpmeso]

Jeff Sickel <jas@corpus-callosum.com> wrote:
 |> On Sep 30, 2015, at 2:59 AM, Charles Forsyth <charles.fo\
 |> rsyth@gmail.com> wrote:
 |> 
 |> Here's a small but representative example.
 |
 |That’s just an example of a C file.  The joy of Git is the\
 | rest of the requirements to actually use it:
 |
 |- bash

Isn't a POSIX shell enough for the core?  I only have mksh at hand
as an alternative right now, but that looks good (on my old box
i think that was /bin/sh, too):

  ?0[sdaoden@wales git.git-no_reduce]$ for i in *.sh; do mksh -n $i;done
  ?0[sdaoden@wales git.git-no_reduce]$

 |- perl5

That seems to have been a temporary oops from a Mr. Eric Sunshine
who messed up git(1) circa at the end of June; i've ran into this,
but someone else just did one or two days before me (in august?),
so this really was the replacement of a working sh/sed/awk thing
with the same in perl, blowing the NO_PERL configuration option
for two months (and multiple releases).

The shown git reference is really nice and really, really nice to
look at; i've thrown away my progit chapters 6 and 9 (or so).

--steffen

Re: [9fans] off topic - a good Git reference

[lucio]

> I was being sarcastic about the portability of so much contemporary C code.
> You can't just compile it, even in an an ANSI/POSIX environment.

Philosophically, I think that we're chasing the wrong wild goose.
Computer Scientists (I've been giving Dijkstra some attention, of
late) ought to focus on how to get programmers to express models and
algorithms accurately and let engineers figure how to translate these
into Turing machines, efficiently.

Instead, we let engineers dictate to sientists how to encrypt problems
that are not nails so that hammers can deal with them.

Lucio.

Re: [9fans] off topic - a good Git reference

[hiro]

lucio, I don't know what you're refering to. Perhaps because I don't
understand POSIX, but also to understand your abstraction I would need
some more explanation.

Re: [9fans] off topic - a good Git reference

[Ori Bernstein]

I have managed to get libgit2 ported to Plan 9, but I haven't had enough time
to actually take a shot at making a viable client yet.

    https://bitbucket.org/oridb/libgit2

It needed a couple of changes to APE to make it work, but they've been integrated
into 9front.

On Wed, 30 Sep 2015 08:18:33 +0100, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> On 30 September 2015 at 04:11, erik quanstrom <quanstro@quanstro.net> wrote:
>
> > > > is there someone else interested in write a git tool for plan 9 ?
>
>
> it would be useful, to access git repositories directly. unfortunately, git
> is a C program, so it's not very portable.


--
    Ori Bernstein

Re: [9fans] off topic - a good Git reference

[lucio]

> I have managed to get libgit2 ported to Plan 9

Contrary to all I've said so far, I think this is good.

Changes to APE, maybe less so, but maybe they ARE valuable?

I need to figure how to track 9atom and 9front without losing 9legacy.
But I've always viewed three-way merges as daunting, never mind
higher-order ones.

Lucio.

Re: [9fans] off topic - a good Git reference

[lucio]

> it would be useful, to access git repositories directly. unfortunately, git
> is a C program, so it's not very portable.

Hey, it could be C++ and even less portable, at least to Plan 9.

If I wasn't stuck thinking that I could do better with a (very fancy)
synthetic file server, Venti-like archival storage, a dynamic "proto"
mechanism and an rc-like shell with its own /rc/bin directory of
commands and scripts, I'd be tempted to do the port.

And when I looked at the Git sources, they looked as un-portable as
Charles suggests.

Lucio.

Re: [9fans] off topic - a good Git reference

[Brantley Coile]

How can it be a secret 'society' if there's just one member for each secret society?

Sent from my iPad

> On Sep 29, 2015, at 11:11 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> 
>> On Tue Sep 29 12:45:25 PDT 2015, khm@sciops.net wrote:
>>> On Tue, Sep 29, 2015 at 02:18:20PM -0300, Tiago Natel wrote:
>>> is there someone else interested in write a git tool for plan 9 ?
>>> 
>>> []'s
>> 
>> This has been written.  You just need to fill out a Secret Plan 9 Super
>> Secret Society application and find three Bilderbergs to vouch for you.
> 
> it's the super secret plan 9 society here!  we *hate* the sp9sss.
> 
> to the original question: i haven't used git on plan 9.  sorry, i don't have
> any useful info.
> 
> - erik
> 

Re: [9fans] off topic - a good Git reference

[Steve Simon]

> How can it be a secret 'society' if there's just one member for each secret society?

That, my good man, is the biggest secret of all!

☺

-Steve

Re: [9fans] off topic - a good Git reference

[erik quanstrom]

On Wed Sep 30 03:03:36 PDT 2015, brantleycoile@me.com wrote:
> How can it be a secret 'society' if there's just one member for each secret society?
>
> Sent from my iPad
>
> > On Sep 29, 2015, at 11:11 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> >
> >> On Tue Sep 29 12:45:25 PDT 2015, khm@sciops.net wrote:
> >>> On Tue, Sep 29, 2015 at 02:18:20PM -0300, Tiago Natel wrote:
> >>> is there someone else interested in write a git tool for plan 9 ?
> >>>
> >>> []'s
> >>
> >> This has been written.  You just need to fill out a Secret Plan 9 Super
> >> Secret Society application and find three Bilderbergs to vouch for you.
> >
> > it's the super secret plan 9 society here!  we *hate* the sp9sss.
> >
> > to the original question: i haven't used git on plan 9.  sorry, i don't have
> > any useful info.

the members talk to themselves?

- erik

Re: [9fans] off topic - a good Git reference

[Prof Brucee]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

And buy a t-shirt.
On 30/09/2015 5:44 AM, "Kurt H Maier" <khm@sciops.net> wrote:

> On Tue, Sep 29, 2015 at 02:18:20PM -0300, Tiago Natel wrote:
> > is there someone else interested in write a git tool for plan 9 ?
> >
> > []'s
>
> This has been written.  You just need to fill out a Secret Plan 9 Super
> Secret Society application and find three Bilderbergs to vouch for you.
>
> khm
>
>

[-- Attachment #2: Type: text/html, Size: 674 bytes --]

Re: [9fans] off topic - a good Git reference

[lego12239]

On Tue, Sep 29, 2015 at 02:18:20PM -0300, Tiago Natel wrote:
> is there someone else interested in write a git tool for plan 9 ?

  May be me. But now i have no time for this :-).

-- 
Неманов Олег (Nemanov Oleg)