On April 2, 2019 4:41:09 AM UTC, o...@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

Reply via email to