I would throw in a vote in favor of a good git client. It's something I use daily and I find it works well with distributed people working on the same project. Which is a situation Linux and plan9 share.
Last time I looked at how it was put together the 'core' was actually just a small handful of commands most of which where implementing the content addressed filesystem (that git essentially is). All the other commands just built on top of those basic ones to implement handy features or more user friendly-ness. As suggested above I also think git should fit reasonably well with plan9's filesystem interface. To continue throwing out half-baked ideas. I would envision something like: cp /usr/glenda/myproject /n/git/staging ##Add project files to staging echo "Add new feature X" > /n/git/commit ###Commit staging directory with message cat /n/git/log # view all logs echo 34nb432 > /n/git/log ###Tell it you want to read log 34nb... cat /n/git/log ###Reads out log selected with previous command echo "my-git-repo.example.com:HEAD" > /n/git/pull ###Pull changes from online repo Of course, as git just wants another .git directory that could just as easily be echo "/n/sources" > /n/git/pull ###Pull changes to sources If it was decided that someone might like to try to port git I'd imagine you could just port the basic boiler plate commands, and a few higher level ones, ignoring the fancy util commands like bisect that are unlikely to be needed often and tackle those as-needed. But that comment could stand some verification. http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain is an interesting read if anyone is interested.
