Porting is annoying, and ape (the ansi/posix emulation environment) is a separate world that’s no fun to use. It also comes with interoperability caveats and issues when using the native plan9 libraries. Additionally, the things that libgit2 helps with are the things I want to do in shell script. And finally:

  term% cd git9
  term% wc -l `{du -a . | awk '/.*\.[chy]$/{print $2}'}
     108 ./conf.c
     378 ./fetch.c
     839 ./fs.c
     174 ./git.h
      62 ./objset.c
     828 ./pack.c
     264 ./save.c
     489 ./send.c
     228 ./util.c
    3370 total

Compared to:

  term% cd libgit2
  term% wc -l `{du -a . | awk '/.*\.[chy]$/{print $2}' }
      <elided list of ~900 files>
      270404 total

Even ignoring tests, examples, and external deps:

  term% wc -l `{du -a . | \
           awk '/.*\.[chy]$/{print $2}' | \
           grep -v 'tests|deps|examples' }
      <elided list of files>
      138077 total

In other words, depending on how you count, there’s between 1.2% and 2.4% the amount of C code to maintain, update, and understand in this implementation. And sure, this implementation will grow, but it’s likely to stay within the single digit percentages of libgit2’s size.

As in git add -p for Interactive Staging?

You can try working on one thing at a time, or you can leverage your favourite editor’s functionality, if possible. VIM (and I bet many others) can do partial writes to files, so if you keep touching many areas but want to stage/commit them one by one, write the specific areas only and proceed as usual.

Developers have been surviving without those bells and whistles for a long time. I do use it now and then when things got too complicated, but that’s not (necessarily) a good thing: I wish I never run into this in the first place.

After git/add foo.c, which state is foo.c: “dirty” or “committed”? It’s not committed and not untracked, so I guess it must be “dirty”. But if it’s again modified in the workspace… then what?

Naively snapshotting an entire directory will pick up in-progress files, generated outputs, and other undesirable stragglers. We need a method to mark files that should be included in a commit.

git/add is the tool for this. It does not copy files anywhere, it just marks a file as snapshot-worthy.

git/commit will snapshot whatever is in the working directory at the time you call it. The concept of a staging area is simply gone. This reduces the amount of state I need to track in my head, improving usability. (See, for example, the usability studies done by the gitless folks: https://spderosso.github.io/oopsla16.pdf, https://gitless.com/)

One major missing feature that results from this decision is partial commits. This will be supported by explicitly listing the files to snapshot when committing, as in git/commit path/to/file. That will work by creating a fresh namespace from /mnt/git, and binding in just the files passed as dirty. Something like:

     scratch=/tmp/commit.$pid
     mkdir $scratch
     @{ # subshell for fresh namespace, so binds are cleaned up.
         rfork n
         # stitch together a view of the files that we'd like to snapshot.
         for(f in $files)
               bind $file $scratch/$file
         bind -ac .git $scratch/.git
         bind -a /mnt/git/HEAD/tree $scratch
         # commit that virtual view.
         cd $scratch
         git/commit
     }
     rm $scratch

(Edited for clarity)