* Re: [9fans] Git/fs: Possibly Usable
2019-04-02 4:41 ori
@ 2019-04-02 6:10 ` Skip Tavakkolian
2019-04-02 13:32 ` Dave MacFarlane
` (4 subsequent siblings)
5 siblings, 0 replies; 32+ messages in thread
From: Skip Tavakkolian @ 2019-04-02 6:10 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 5608 bytes --]
Very cool! Thank you.
On Mon, Apr 1, 2019 at 9:48 PM <ori@eigenstate.org> wrote:
> It was mentioned on this list a short while ago. Now, it's
> more or less at the point where it works for me. Expect
> many bugs and problems, and many more missing tools, but
> "the rest is just scripting".
>
> One caveat I have: Git's index file format is a bit
> boneheaded, so I'm ignoring it. The index doesn't affect
> the wire protocol, so this isn't an interoperability issue,
> unless you share the same physical repository on both
> Plan 9 and Unix. If you do, expect them to get out of
> sync on uncommitted but added files.
>
> In fact, the entire concept of the staging area has been
> removed, as it's both confusing and clunky. There are now
> only three states that files can be in: 'untracked',
> 'dirty', and 'committed'. Tracking is done with empty
> files under .git/index9/{removed,tracked}/path/to/file.
>
> It's implemented in Plan 9 flavor C, and provides tools
> for writing repository contents, and a file system for
> read-only access, which will mirror the current state of
> the repository.
>
> The code is here: https://bitbucket.org/oridb/git9
>
> Install with `mk install`. There's no recursive binding
> of directories, so you need to union /rc/bin/git and
> $objtype/bin/git` by hand.
>
> Documentation has not yet been written. You'll need to
> read the source.
>
> Some usage examples:
>
> git/clone git://git.eigenstate.org/git/ori/mc.git
> git/log
> cd subdir/name
> git/add foo.c
> git/commit
> git/push
>
> Scripts will generally mount git/fs as needed to do
> their work, but if you want to browse the repository
> manually, run it yourself. You'll get `/n/git` mounted,
> with the following contents:
>
> /n/git/object: The objects in the repo.
> /n/git/branch: The branches in the repo.
> /n/git/ctl: A file showing the status of the repo.
> Currently, it only shows the
> current branch.
>
> Commits are presented as directories with the following
> contents:
>
> author: A file containing the author name
> hash: A file containing the commit hash
> parent: A file containing the commit parents, one per line.
> msg: A file containing the log message for that commit
> tree: A directory containing a view of the repository.
>
> So, for example:
>
> % ls /n/git/branch/heads/master
> /n/git/branch/heads/master/author
> /n/git/branch/heads/master/hash
> /n/git/branch/heads/master/msg
> /n/git/branch/heads/master/parent
> /n/git/branch/heads/master/tree
> % cat /n/git/branch/heads/master/hash
> 7d539a7c08aba3f31b3913e0efef11c43ea9
>
> # This is the same commit, with the same contents.
> % ls /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/author
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/hash
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/msg
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/parent
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/tree
>
> # what git/diff will hopefully do more concisely soon, filtering
> # out the non-git files.
> ape/diff -ur /n/git/branch/heads/master/tree .
> Only in .: .git
> Only in .: debug
> diff -ur /n/git/branch/heads/master/tree/fold.myr ./fold.myr
> --- /n/git/branch/heads/master/tree/fold.myr Wed Dec 31
> 16:00:00 1969
> +++ ./fold.myr Mon Apr 1 21:39:06 2019
> @@ -6,6 +6,8 @@
> const foldexpr : (e : expr# -> std.option(constval))
> ;;
>
> +/* Look, diffing files just works, and I don't need any fancy
> glue! */
> +
> const foldexpr = {e
> match e
> | &(`Eident &[.sc=`Sclassenum, .name=name, .ty=`Tyenum
> &(`Body enum)]):
> Only in .: refs
>
>
> The following utilities and binaries are provided:
>
> fs: The git filesystem.
> fetch: The protocol bits for getting data from a git server.
> send: The protocol bits for sending data to a git server.
> save: The gnarly bits for storing the files for a commit.
> conf: A program to extract information from a config file.
> clone: Clones a repository.
> commit: Commits a snapshot of the working directory.
> log: Prints the contents of a commmit log.
> add: Tells the repository to add a file to the next commit.
> walk: `du`, but for git status.
>
>
> Supported protocols: git:// and git+ssh://. If someone
> implements others, I'll gladly accept patches.
>
> TODOs:
> git/mkpatch: Generate a 'git am' compatible patch.
> git/apply: Apply a diff.
> git/diff: Wrapper wrapper around git/walk that
> diffs the changed files.
> git/merge: Yup, what it says on the label. Should
> also be a script around git/fs.
> git/log: Need to figure out how to make it filter
> by files.
> /n/git/HEAD: add /n/git/head subtree which points
> to the current commit.
>
> ...And a whole bunch more.
>
>
>
[-- Attachment #2: Type: text/html, Size: 6813 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [9fans] Git/fs: Possibly Usable
2019-04-02 4:41 ori
2019-04-02 6:10 ` Skip Tavakkolian
@ 2019-04-02 13:32 ` Dave MacFarlane
2019-04-02 14:37 ` Kyohei Kadota
` (3 subsequent siblings)
5 siblings, 0 replies; 32+ messages in thread
From: Dave MacFarlane @ 2019-04-02 13:32 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Tue, Apr 2, 2019 at 12:49 AM <ori@eigenstate.org> wrote:
> One caveat I have: Git's index file format is a bit
> boneheaded, so I'm ignoring it. The index doesn't affect
> the wire protocol, so this isn't an interoperability issue,
> unless you share the same physical repository on both
> Plan 9 and Unix. If you do, expect them to get out of
> sync on uncommitted but added files.
>
What problems did you have with the index format? In my experience
it was relatively sane (relative to the pack protocol/format, I mean,
which is a pretty low bar to set.)
- Dave
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [9fans] Git/fs: Possibly Usable
2019-04-02 4:41 ori
2019-04-02 6:10 ` Skip Tavakkolian
2019-04-02 13:32 ` Dave MacFarlane
@ 2019-04-02 14:37 ` Kyohei Kadota
2019-04-03 10:38 ` Giacomo
` (2 subsequent siblings)
5 siblings, 0 replies; 32+ messages in thread
From: Kyohei Kadota @ 2019-04-02 14:37 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Cool! It's very interesting what implement Git in native Plan 9 style to me.
2019年4月2日(火) 13:48 <ori@eigenstate.org>:
>
> It was mentioned on this list a short while ago. Now, it's
> more or less at the point where it works for me. Expect
> many bugs and problems, and many more missing tools, but
> "the rest is just scripting".
>
> One caveat I have: Git's index file format is a bit
> boneheaded, so I'm ignoring it. The index doesn't affect
> the wire protocol, so this isn't an interoperability issue,
> unless you share the same physical repository on both
> Plan 9 and Unix. If you do, expect them to get out of
> sync on uncommitted but added files.
>
> In fact, the entire concept of the staging area has been
> removed, as it's both confusing and clunky. There are now
> only three states that files can be in: 'untracked',
> 'dirty', and 'committed'. Tracking is done with empty
> files under .git/index9/{removed,tracked}/path/to/file.
>
> It's implemented in Plan 9 flavor C, and provides tools
> for writing repository contents, and a file system for
> read-only access, which will mirror the current state of
> the repository.
>
> The code is here: https://bitbucket.org/oridb/git9
>
> Install with `mk install`. There's no recursive binding
> of directories, so you need to union /rc/bin/git and
> $objtype/bin/git` by hand.
>
> Documentation has not yet been written. You'll need to
> read the source.
>
> Some usage examples:
>
> git/clone git://git.eigenstate.org/git/ori/mc.git
> git/log
> cd subdir/name
> git/add foo.c
> git/commit
> git/push
>
> Scripts will generally mount git/fs as needed to do
> their work, but if you want to browse the repository
> manually, run it yourself. You'll get `/n/git` mounted,
> with the following contents:
>
> /n/git/object: The objects in the repo.
> /n/git/branch: The branches in the repo.
> /n/git/ctl: A file showing the status of the repo.
> Currently, it only shows the current branch.
>
> Commits are presented as directories with the following
> contents:
>
> author: A file containing the author name
> hash: A file containing the commit hash
> parent: A file containing the commit parents, one per line.
> msg: A file containing the log message for that commit
> tree: A directory containing a view of the repository.
>
> So, for example:
>
> % ls /n/git/branch/heads/master
> /n/git/branch/heads/master/author
> /n/git/branch/heads/master/hash
> /n/git/branch/heads/master/msg
> /n/git/branch/heads/master/parent
> /n/git/branch/heads/master/tree
> % cat /n/git/branch/heads/master/hash
> 7d539a7c08aba3f31b3913e0efef11c43ea9
>
> # This is the same commit, with the same contents.
> % ls /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/author
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/hash
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/msg
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/parent
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/tree
>
> # what git/diff will hopefully do more concisely soon, filtering
> # out the non-git files.
> ape/diff -ur /n/git/branch/heads/master/tree .
> Only in .: .git
> Only in .: debug
> diff -ur /n/git/branch/heads/master/tree/fold.myr ./fold.myr
> --- /n/git/branch/heads/master/tree/fold.myr Wed Dec 31 16:00:00 1969
> +++ ./fold.myr Mon Apr 1 21:39:06 2019
> @@ -6,6 +6,8 @@
> const foldexpr : (e : expr# -> std.option(constval))
> ;;
>
> +/* Look, diffing files just works, and I don't need any fancy glue! */
> +
> const foldexpr = {e
> match e
> | &(`Eident &[.sc=`Sclassenum, .name=name, .ty=`Tyenum &(`Body enum)]):
> Only in .: refs
>
>
> The following utilities and binaries are provided:
>
> fs: The git filesystem.
> fetch: The protocol bits for getting data from a git server.
> send: The protocol bits for sending data to a git server.
> save: The gnarly bits for storing the files for a commit.
> conf: A program to extract information from a config file.
> clone: Clones a repository.
> commit: Commits a snapshot of the working directory.
> log: Prints the contents of a commmit log.
> add: Tells the repository to add a file to the next commit.
> walk: `du`, but for git status.
>
>
> Supported protocols: git:// and git+ssh://. If someone
> implements others, I'll gladly accept patches.
>
> TODOs:
> git/mkpatch: Generate a 'git am' compatible patch.
> git/apply: Apply a diff.
> git/diff: Wrapper wrapper around git/walk that
> diffs the changed files.
> git/merge: Yup, what it says on the label. Should
> also be a script around git/fs.
> git/log: Need to figure out how to make it filter
> by files.
> /n/git/HEAD: add /n/git/head subtree which points
> to the current commit.
>
> ...And a whole bunch more.
>
>
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [9fans] Git/fs: Possibly Usable
2019-04-02 4:41 ori
` (2 preceding siblings ...)
2019-04-02 14:37 ` Kyohei Kadota
@ 2019-04-03 10:38 ` Giacomo
2019-04-03 18:29 ` Skip Tavakkolian
2019-07-08 19:54 ` Ori Bernstein
5 siblings, 0 replies; 32+ messages in thread
From: Giacomo @ 2019-04-03 10:38 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs, ori
On April 2, 2019 4:41:09 AM UTC, ori@eigenstate.org wrote:
>It was mentioned on this list a short while ago. Now, it's
>more or less at the point where it works for me. Expect
>many bugs and problems, and many more missing tools, but
>"the rest is just scripting".
>
>One caveat I have: Git's index file format is a bit
>boneheaded, so I'm ignoring it. The index doesn't affect
>the wire protocol, so this isn't an interoperability issue,
>unless you share the same physical repository on both
>Plan 9 and Unix. If you do, expect them to get out of
>sync on uncommitted but added files.
>
>In fact, the entire concept of the staging area has been
>removed, as it's both confusing and clunky. There are now
>only three states that files can be in: 'untracked',
>'dirty', and 'committed'. Tracking is done with empty
>files under .git/index9/{removed,tracked}/path/to/file.
>
>It's implemented in Plan 9 flavor C, and provides tools
>for writing repository contents, and a file system for
>read-only access, which will mirror the current state of
>the repository.
>
>The code is here: https://bitbucket.org/oridb/git9
>
>Install with `mk install`. There's no recursive binding
>of directories, so you need to union /rc/bin/git and
>$objtype/bin/git` by hand.
>
>Documentation has not yet been written. You'll need to
>read the source.
>
>Some usage examples:
>
> git/clone git://git.eigenstate.org/git/ori/mc.git
> git/log
> cd subdir/name
> git/add foo.c
> git/commit
> git/push
>
>Scripts will generally mount git/fs as needed to do
>their work, but if you want to browse the repository
>manually, run it yourself. You'll get `/n/git` mounted,
>with the following contents:
>
> /n/git/object: The objects in the repo.
> /n/git/branch: The branches in the repo.
> /n/git/ctl: A file showing the status of the repo.
> Currently, it only shows the current branch.
>
>Commits are presented as directories with the following
>contents:
>
> author: A file containing the author name
> hash: A file containing the commit hash
> parent: A file containing the commit parents, one per line.
> msg: A file containing the log message for that commit
> tree: A directory containing a view of the repository.
>
>So, for example:
>
> % ls /n/git/branch/heads/master
> /n/git/branch/heads/master/author
> /n/git/branch/heads/master/hash
> /n/git/branch/heads/master/msg
> /n/git/branch/heads/master/parent
> /n/git/branch/heads/master/tree
> % cat /n/git/branch/heads/master/hash
> 7d539a7c08aba3f31b3913e0efef11c43ea9
>
> # This is the same commit, with the same contents.
> % ls /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/author
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/hash
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/msg
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/parent
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/tree
>
> # what git/diff will hopefully do more concisely soon, filtering
> # out the non-git files.
> ape/diff -ur /n/git/branch/heads/master/tree .
> Only in .: .git
> Only in .: debug
> diff -ur /n/git/branch/heads/master/tree/fold.myr ./fold.myr
> --- /n/git/branch/heads/master/tree/fold.myr Wed Dec 31 16:00:00 1969
> +++ ./fold.myr Mon Apr 1 21:39:06 2019
> @@ -6,6 +6,8 @@
> const foldexpr : (e : expr# -> std.option(constval))
> ;;
>
> +/* Look, diffing files just works, and I don't need any fancy glue!
>*/
> +
> const foldexpr = {e
> match e
> | &(`Eident &[.sc=`Sclassenum, .name=name, .ty=`Tyenum &(`Body
>enum)]):
> Only in .: refs
>
>
>The following utilities and binaries are provided:
>
> fs: The git filesystem.
> fetch: The protocol bits for getting data from a git server.
> send: The protocol bits for sending data to a git server.
> save: The gnarly bits for storing the files for a commit.
> conf: A program to extract information from a config file.
> clone: Clones a repository.
> commit: Commits a snapshot of the working directory.
> log: Prints the contents of a commmit log.
> add: Tells the repository to add a file to the next commit.
> walk: `du`, but for git status.
>
>
>Supported protocols: git:// and git+ssh://. If someone
>implements others, I'll gladly accept patches.
>
>TODOs:
> git/mkpatch: Generate a 'git am' compatible patch.
> git/apply: Apply a diff.
> git/diff: Wrapper wrapper around git/walk that
> diffs the changed files.
> git/merge: Yup, what it says on the label. Should
> also be a script around git/fs.
> git/log: Need to figure out how to make it filter
> by files.
> /n/git/HEAD: add /n/git/head subtree which points
> to the current commit.
>
>...And a whole bunch more.
Impressive!
I didn't imagine one could implement git in so few lines of C! Thanks for challenging my assumptions!
I'd like to port it to Jehanne but I cannot find a license in the repository, so in theory it's "all rights reserved" under most jurisdictions.
What's your take on this?
Did you intend to put it under public domain instead? Maybe MIT? Or LPL?
Giacomo
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [9fans] Git/fs: Possibly Usable
2019-04-02 4:41 ori
` (3 preceding siblings ...)
2019-04-03 10:38 ` Giacomo
@ 2019-04-03 18:29 ` Skip Tavakkolian
2019-04-03 20:14 ` David du Colombier
2019-04-03 20:23 ` Ori Bernstein
2019-07-08 19:54 ` Ori Bernstein
5 siblings, 2 replies; 32+ messages in thread
From: Skip Tavakkolian @ 2019-04-03 18:29 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 5749 bytes --]
Hi,
The avl library doesn't match up to 9legacy version. Any ideas?
BTW, I think your notes on this message are a great start for a README.
Thanks,
-Skip
On Mon, Apr 1, 2019 at 9:48 PM <ori@eigenstate.org> wrote:
> It was mentioned on this list a short while ago. Now, it's
> more or less at the point where it works for me. Expect
> many bugs and problems, and many more missing tools, but
> "the rest is just scripting".
>
> One caveat I have: Git's index file format is a bit
> boneheaded, so I'm ignoring it. The index doesn't affect
> the wire protocol, so this isn't an interoperability issue,
> unless you share the same physical repository on both
> Plan 9 and Unix. If you do, expect them to get out of
> sync on uncommitted but added files.
>
> In fact, the entire concept of the staging area has been
> removed, as it's both confusing and clunky. There are now
> only three states that files can be in: 'untracked',
> 'dirty', and 'committed'. Tracking is done with empty
> files under .git/index9/{removed,tracked}/path/to/file.
>
> It's implemented in Plan 9 flavor C, and provides tools
> for writing repository contents, and a file system for
> read-only access, which will mirror the current state of
> the repository.
>
> The code is here: https://bitbucket.org/oridb/git9
>
> Install with `mk install`. There's no recursive binding
> of directories, so you need to union /rc/bin/git and
> $objtype/bin/git` by hand.
>
> Documentation has not yet been written. You'll need to
> read the source.
>
> Some usage examples:
>
> git/clone git://git.eigenstate.org/git/ori/mc.git
> git/log
> cd subdir/name
> git/add foo.c
> git/commit
> git/push
>
> Scripts will generally mount git/fs as needed to do
> their work, but if you want to browse the repository
> manually, run it yourself. You'll get `/n/git` mounted,
> with the following contents:
>
> /n/git/object: The objects in the repo.
> /n/git/branch: The branches in the repo.
> /n/git/ctl: A file showing the status of the repo.
> Currently, it only shows the
> current branch.
>
> Commits are presented as directories with the following
> contents:
>
> author: A file containing the author name
> hash: A file containing the commit hash
> parent: A file containing the commit parents, one per line.
> msg: A file containing the log message for that commit
> tree: A directory containing a view of the repository.
>
> So, for example:
>
> % ls /n/git/branch/heads/master
> /n/git/branch/heads/master/author
> /n/git/branch/heads/master/hash
> /n/git/branch/heads/master/msg
> /n/git/branch/heads/master/parent
> /n/git/branch/heads/master/tree
> % cat /n/git/branch/heads/master/hash
> 7d539a7c08aba3f31b3913e0efef11c43ea9
>
> # This is the same commit, with the same contents.
> % ls /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/author
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/hash
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/msg
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/parent
> /n/git/object/7d539a7c08aba3f31b3913e0efef11c43ea9f9ef/tree
>
> # what git/diff will hopefully do more concisely soon, filtering
> # out the non-git files.
> ape/diff -ur /n/git/branch/heads/master/tree .
> Only in .: .git
> Only in .: debug
> diff -ur /n/git/branch/heads/master/tree/fold.myr ./fold.myr
> --- /n/git/branch/heads/master/tree/fold.myr Wed Dec 31
> 16:00:00 1969
> +++ ./fold.myr Mon Apr 1 21:39:06 2019
> @@ -6,6 +6,8 @@
> const foldexpr : (e : expr# -> std.option(constval))
> ;;
>
> +/* Look, diffing files just works, and I don't need any fancy
> glue! */
> +
> const foldexpr = {e
> match e
> | &(`Eident &[.sc=`Sclassenum, .name=name, .ty=`Tyenum
> &(`Body enum)]):
> Only in .: refs
>
>
> The following utilities and binaries are provided:
>
> fs: The git filesystem.
> fetch: The protocol bits for getting data from a git server.
> send: The protocol bits for sending data to a git server.
> save: The gnarly bits for storing the files for a commit.
> conf: A program to extract information from a config file.
> clone: Clones a repository.
> commit: Commits a snapshot of the working directory.
> log: Prints the contents of a commmit log.
> add: Tells the repository to add a file to the next commit.
> walk: `du`, but for git status.
>
>
> Supported protocols: git:// and git+ssh://. If someone
> implements others, I'll gladly accept patches.
>
> TODOs:
> git/mkpatch: Generate a 'git am' compatible patch.
> git/apply: Apply a diff.
> git/diff: Wrapper wrapper around git/walk that
> diffs the changed files.
> git/merge: Yup, what it says on the label. Should
> also be a script around git/fs.
> git/log: Need to figure out how to make it filter
> by files.
> /n/git/HEAD: add /n/git/head subtree which points
> to the current commit.
>
> ...And a whole bunch more.
>
>
>
[-- Attachment #2: Type: text/html, Size: 7032 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [9fans] Git/fs: Possibly Usable
2019-04-03 18:29 ` Skip Tavakkolian
@ 2019-04-03 20:14 ` David du Colombier
2019-04-03 20:23 ` Ori Bernstein
1 sibling, 0 replies; 32+ messages in thread
From: David du Colombier @ 2019-04-03 20:14 UTC (permalink / raw)
To: 9fans
> The avl library doesn't match up to 9legacy version. Any ideas?
>
> BTW, I think your notes on this message are a great start for a README.
git9 seems to use 9front's libavl, which is a rewrite of Plan 9's libavl.
9legacy uses the original Plan9's libavl.
Please try this patch: http://9legacy.org/9legacy/patch/git9-avl.diff
--
David du Colombier
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Git/fs: Possibly Usable
2019-04-03 18:29 ` Skip Tavakkolian
2019-04-03 20:14 ` David du Colombier
@ 2019-04-03 20:23 ` Ori Bernstein
2019-04-04 0:00 ` Skip Tavakkolian
2019-04-04 1:22 ` Ori Bernstein
1 sibling, 2 replies; 32+ messages in thread
From: Ori Bernstein @ 2019-04-03 20:23 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Wed, 3 Apr 2019 11:29:30 -0700
Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> Hi,
>
> The avl library doesn't match up to 9legacy version. Any ideas?
Looking at a few options. I can just say "well, patch it", but it'd
be nice to see the various plan9s playing better with each other.
There are a few options. The easy ones:
- I can bundle the 9front libavl in git9.
- I can remove the libavl usage, possibly replacing with
the objset implementation I already have.
The harder ones:
- 9front can provide compatibility with 9legacy libavl
- 9legacy can adopt the 9front libavl API.
The first two are easy. The other two involve herding cats,
but would make it possible for more code to be shared. Given
how few people are actually writing code on plan 9, it would
be nice to share what is there.
Right now, I'm leaning towards the second option, because all
I really use libavl for is a key-value lookup.
> BTW, I think your notes on this message are a great start for a README.
Already done.
--
Ori Bernstein <ori@eigenstate.org>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Git/fs: Possibly Usable
2019-04-03 20:23 ` Ori Bernstein
@ 2019-04-04 0:00 ` Skip Tavakkolian
2019-04-04 0:34 ` Kurt H Maier
2019-04-04 1:22 ` Ori Bernstein
1 sibling, 1 reply; 32+ messages in thread
From: Skip Tavakkolian @ 2019-04-04 0:00 UTC (permalink / raw)
To: Ori Bernstein; +Cc: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]
I now realize there are two different libavl's. It's easy enough to copy
from 9front repo (hopefully there are no cascading dependencies).
9front maintainers, can anyone speak to technical reasons for creating a
new version rather than fixing existing? Also, any thoughts on changing the
name slightly so they can both be on the same system? maybe libAVL?
Thanks,
-Skip
On Wed, Apr 3, 2019 at 1:23 PM Ori Bernstein <ori@eigenstate.org> wrote:
> On Wed, 3 Apr 2019 11:29:30 -0700
> Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
>
> > Hi,
> >
> > The avl library doesn't match up to 9legacy version. Any ideas?
>
> Looking at a few options. I can just say "well, patch it", but it'd
> be nice to see the various plan9s playing better with each other.
>
> There are a few options. The easy ones:
>
> - I can bundle the 9front libavl in git9.
> - I can remove the libavl usage, possibly replacing with
> the objset implementation I already have.
>
> The harder ones:
>
> - 9front can provide compatibility with 9legacy libavl
> - 9legacy can adopt the 9front libavl API.
>
> The first two are easy. The other two involve herding cats,
> but would make it possible for more code to be shared. Given
> how few people are actually writing code on plan 9, it would
> be nice to share what is there.
>
> Right now, I'm leaning towards the second option, because all
> I really use libavl for is a key-value lookup.
>
> > BTW, I think your notes on this message are a great start for a README.
>
> Already done.
>
> --
> Ori Bernstein <ori@eigenstate.org>
>
[-- Attachment #2: Type: text/html, Size: 2261 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Git/fs: Possibly Usable
2019-04-04 0:00 ` Skip Tavakkolian
@ 2019-04-04 0:34 ` Kurt H Maier
0 siblings, 0 replies; 32+ messages in thread
From: Kurt H Maier @ 2019-04-04 0:34 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Wed, Apr 03, 2019 at 05:00:15PM -0700, Skip Tavakkolian wrote:
> 9front maintainers, can anyone speak to technical reasons for creating a
> new version rather than fixing existing? Also, any thoughts on changing the
> name slightly so they can both be on the same system? maybe libAVL?
In 2016 spew wrote libbst, which is a binary search tree library that
supports both AVL and left-leaning red-black tree. While he was at it
he wrote a faster and simpler avl implementation, and fixed venti and
nupas to work with it. Since those were the only two things in the tree
that used AVL, nobody really cared if the old implementation went away.
I'm not sure what the advantage is to reintroducing it to 9front (aside
from the desire for zen-garden reliquaries). The programs that use the
old API can be counted on one hand and fixing them is not difficult.
The question was raised, at the time, if the old one might have been
hand-tuned for some venti-related performance characteristics, but I
don't think anyone followed through on measuring the difference. If
there are such idiosyncracies in the old code, they were not documented.
khm
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Git/fs: Possibly Usable
2019-04-03 20:23 ` Ori Bernstein
2019-04-04 0:00 ` Skip Tavakkolian
@ 2019-04-04 1:22 ` Ori Bernstein
1 sibling, 0 replies; 32+ messages in thread
From: Ori Bernstein @ 2019-04-04 1:22 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Wed, 3 Apr 2019 13:23:08 -0700
Ori Bernstein <ori@eigenstate.org> wrote:
> - I can remove the libavl usage, possibly replacing with
> the objset implementation I already have.
Did this one. Turned out to save a couple of lines, in the end.
--
Ori Bernstein <ori@eigenstate.org>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Git/fs: Possibly Usable
2019-04-02 4:41 ori
` (4 preceding siblings ...)
2019-04-03 18:29 ` Skip Tavakkolian
@ 2019-07-08 19:54 ` Ori Bernstein
2019-07-12 18:27 ` Patrick Marchand
5 siblings, 1 reply; 32+ messages in thread
From: Ori Bernstein @ 2019-07-08 19:54 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Mon, 1 Apr 2019 21:41:09 -0700
ori@eigenstate.org wrote:
> It was mentioned on this list a short while ago. Now, it's
> more or less at the point where it works for me. Expect
> many bugs and problems, and many more missing tools, but
> "the rest is just scripting".
An update: I'm now using this git implementation on a daily
basis. It's hosting its own development now, and tons of
bugs have been fixed.
All commits in the git mirror here were made with git9 on 9front:
https://github.com/oridb/git9
I'm also keeping the old mirror in hg alive:
https://bitbucket.org/oridb/git9
There's one incompatibility that I'm aware of with 9legacy, where
I use `$split{...} syntax in rc to make files with spaces work
cleanly. I don't think 9legacy imported that patch from 9atom.
The remaining missing bits, in my mind:
- UI polish; There's some thought needed about how
the exposed functionality should work.
- Patch import/export: probably git/diff -[pa] for
generating or importing `git format-patch` compatible
style diff.
- Rebase-like functionality would be nice.
- (Low priority, probably won't do it myself, but I'd
take a patch): HTTP protocol. Most places (including
github) serve up git protocol URLS, in the form
git://github.com/user/repo
--
Ori Bernstein <ori@eigenstate.org>
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [9fans] Git/fs: Possibly Usable
2019-07-08 19:54 ` Ori Bernstein
@ 2019-07-12 18:27 ` Patrick Marchand
2019-07-12 20:21 ` Steve Simon
0 siblings, 1 reply; 32+ messages in thread
From: Patrick Marchand @ 2019-07-12 18:27 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Hi Ori,
On 07/08, Ori Bernstein wrote:
> On Mon, 1 Apr 2019 21:41:09 -0700
> ori@eigenstate.org wrote:
>
> > It was mentioned on this list a short while ago. Now, it's
> > more or less at the point where it works for me. Expect
> > many bugs and problems, and many more missing tools, but
> > "the rest is just scripting".
>
> An update: I'm now using this git implementation on a daily
> basis. It's hosting its own development now, and tons of
> bugs have been fixed.
>
Good job ! Cant wait to get the chance to play around with it. I'll
be installing a plan9 server at my home next month so I'll be able
to test in detail then.
Have a good day
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Git/fs: Possibly Usable
2019-07-12 18:27 ` Patrick Marchand
@ 2019-07-12 20:21 ` Steve Simon
2019-07-21 21:06 ` clueelf
0 siblings, 1 reply; 32+ messages in thread
From: Steve Simon @ 2019-07-12 20:21 UTC (permalink / raw)
To: 9fans
I agree 100%, well done Ori, I will be trying this soon,
I am in the process of changing jobs at the moment so
I am a bit distracted but the new job will include git so I
Will be needing it.
-Steve
> On 12 Jul 2019, at 19:27, Patrick Marchand <mail@patrickmarchand.com> wrote:
>
> Hi Ori,
>
> On 07/08, Ori Bernstein wrote:
>> On Mon, 1 Apr 2019 21:41:09 -0700
>> ori@eigenstate.org wrote:
>>
>>> It was mentioned on this list a short while ago. Now, it's
>>> more or less at the point where it works for me. Expect
>>> many bugs and problems, and many more missing tools, but
>>> "the rest is just scripting".
>>
>> An update: I'm now using this git implementation on a daily
>> basis. It's hosting its own development now, and tons of
>> bugs have been fixed.
>>
>
> Good job ! Cant wait to get the chance to play around with it. I'll
> be installing a plan9 server at my home next month so I'll be able
> to test in detail then.
>
> Have a good day
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Git/fs: Possibly Usable
2019-07-12 20:21 ` Steve Simon
@ 2019-07-21 21:06 ` clueelf
2019-07-25 21:59 ` Ori Bernstein
0 siblings, 1 reply; 32+ messages in thread
From: clueelf @ 2019-07-21 21:06 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Thanks Ori!
I pulled it down today and started using it against a few GitHub repos I have. For those who are thinking about using it, it only uses 'git' and 'git+ssh' style URLs, but they work so far without incident.
git/clone git+ssh://git@github.com:tmendoza/9front-user
Once I got keys generated and pushed to github.com, worked just fine. My updates show up as expected.
Great job!
Tony
On 7/12/2019 at 3:22 PM, "Steve Simon" <steve@quintile.net> wrote:
>
>I agree 100%, well done Ori, I will be trying this soon,
>I am in the process of changing jobs at the moment so
>I am a bit distracted but the new job will include git so I
>Will be needing it.
>
>-Steve
>
>
>> On 12 Jul 2019, at 19:27, Patrick Marchand
><mail@patrickmarchand.com> wrote:
>>
>> Hi Ori,
>>
>> On 07/08, Ori Bernstein wrote:
>>> On Mon, 1 Apr 2019 21:41:09 -0700
>>> ori@eigenstate.org wrote:
>>>
>>>> It was mentioned on this list a short while ago. Now, it's
>>>> more or less at the point where it works for me. Expect
>>>> many bugs and problems, and many more missing tools, but
>>>> "the rest is just scripting".
>>>
>>> An update: I'm now using this git implementation on a daily
>>> basis. It's hosting its own development now, and tons of
>>> bugs have been fixed.
>>>
>>
>> Good job ! Cant wait to get the chance to play around with it.
>I'll
>> be installing a plan9 server at my home next month so I'll be
>able
>> to test in detail then.
>>
>> Have a good day
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Git/fs: Possibly Usable
2019-07-21 21:06 ` clueelf
@ 2019-07-25 21:59 ` Ori Bernstein
2019-08-05 18:43 ` Skip Tavakkolian
0 siblings, 1 reply; 32+ messages in thread
From: Ori Bernstein @ 2019-07-25 21:59 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Sun, 21 Jul 2019 16:06:54 -0500
clueelf@tonymendoza.us wrote:
> Thanks Ori!
>
> I pulled it down today and started using it against a few GitHub repos I have. For those who are thinking about using it, it only uses 'git' and 'git+ssh' style URLs, but they work so far without incident.
>
> git/clone git+ssh://git@github.com:tmendoza/9front-user
>
> Once I got keys generated and pushed to github.com, worked just fine. My updates show up as expected.
Good to hear!
--
Ori Bernstein <ori@eigenstate.org>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Git/fs: Possibly Usable
2019-07-25 21:59 ` Ori Bernstein
@ 2019-08-05 18:43 ` Skip Tavakkolian
2019-08-05 21:17 ` erik quanstrom
2019-08-09 5:56 ` Ori Bernstein
0 siblings, 2 replies; 32+ messages in thread
From: Skip Tavakkolian @ 2019-08-05 18:43 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
is this an equivalent fix for 9legacy env? (i'm guessing the answer is no)
% diff clone /bin/git/clone
75c75
< for(f in `$nl{walk -f $tree | sed 's@^'$tree'/*@@'}){
---
> for(f in `{ifs=$nl walk -f $tree | sed 's@^'$tree'/*@@'}){
also, the earliest reference to `$split{...}` notation i found is in 9atom;
can anyone confirm?
On Thu, Jul 25, 2019 at 3:01 PM Ori Bernstein <ori@eigenstate.org> wrote:
> On Sun, 21 Jul 2019 16:06:54 -0500
> clueelf@tonymendoza.us wrote:
>
> > Thanks Ori!
> >
> > I pulled it down today and started using it against a few GitHub repos I
> have. For those who are thinking about using it, it only uses 'git' and
> 'git+ssh' style URLs, but they work so far without incident.
> >
> > git/clone git+ssh://git@github.com:tmendoza/9front-user
> >
> > Once I got keys generated and pushed to github.com, worked just fine.
> My updates show up as expected.
>
> Good to hear!
>
> --
> Ori Bernstein <ori@eigenstate.org>
>
>
[-- Attachment #2: Type: text/html, Size: 1620 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread