Abstract:

This presentation introduces Git on Plan 9, a native implementation (git-n) that leverages Plan 9's file system-centric design to provide a robust and efficient distributed version control system. The speaker offers a refresher on Git's core principles—distributed, snapshot-based, and offline-first—contrasting it with traditional centralized systems and explaining its internal object model (blobs, trees, commits, and pack files). The talk details the pragmatic motivations behind developing git-n (cross-platform development, avoiding burdensome external dependencies like Python), highlighting its lean implementation through C core tools and shell script wrappers, particularly utilizing gitfs for file system-based repo exploration. The discussion also covers git-n's unique features, such as simplified command syntax, improved patch merging for local modifications, and its role in self-hosting Plan 9's development (git.9front.org).

A Git for 9: Distributed Version Control on Plan 9

• 0:00 - Introduction to Git on Plan 9: The speaker apologizes for the unrehearsed nature of the talk, which focuses on a native Git implementation for Plan 9.
• 0:44 - Git Refresher & Core Concepts: Git is a distributed, snapshot-based, offline-first version control system, contrasting with centralized systems like SVN or Venti. It allows peer-to-peer collaboration without a central server.
• 2:10 - Git Repository Internals: A Git repository is a Merkel tree composed of "blobs" (file contents), "trees" (directory structures), and "commits" (snapshots with metadata chaining history). Diffs are generated on demand.
• 4:51 - Objects & Pack Files: Git uses blobs, trees, and commits. For efficiency, objects are stored in "pack files," which deduplicate content (deltas) and enable single-transfer pushes/pulls. The Plan 9 implementation (git-n) uses a faster content-based diffing algorithm than mainline Git.
• 14:00 - Repository Metadata: Key metadata includes .git/head (current branch), ref/heads/branch_name (commit hash), and .git/config (repository configuration). Tags are present but largely ignored in git-n due to laziness and lack of user demand.
• 17:55 - Motivation for git-n: The primary driver was the need for cross-platform development (Unix/Plan 9) without manual syncing or reliance on other VCS like Mercurial (which required porting Python, a significant burden).
• 22:26 - Why git-n over Venti/Mercurial: Venti lacks tools for distributed workflows and offline work. Mercurial was "dead" and its Python dependency was removed from Plan 9, saving over a million lines of code. git-n is useful, small, maintainable, and self-hostable.
• 26:11 - Self-Hosting Plan 9: The Plan 9 operating system (9front.org) is self-hosted using git-n via gitserve, reinforcing the philosophy of using and maintaining core tools. Community hubs like shihub.us also run on git-n, requiring Plan 9 authentication (DP9 I).
• 30:12 - git-n Structure & Tools: The implementation combines C-based core tools (gitsave, gitsend, gitget, gitfs, gitwalk) with shell script wrappers (gitcommit, gitpush, gitpull). gitfs allows treating the Git repository as a file system, simplifying scripting.
• 40:55 - Command Differences from Mainline Git: While many commands are similar, git-n avoids complex features like the "staging area" (git add -p), which the speaker deems "asinine," opting for simpler, more Plan 9-idiomatic solutions like potential shadowfs integration.
• 43:05 - Workflow & Patch Management: Typical workflow involves binding the repo to /, committing with git commit, and pushing. For code review, git diff output can be mailed. git-n also features an enhanced merge logic that allows applying patches even if local modifications exist, making it easier to maintain local changes.
• 47:26 - Hosting Git Servers: The speaker demonstrates setting up unencrypted (gitserve), encrypted (TLS via tlsclient), and authenticated (DP9 I) Git servers on Plan 9, noting it's straightforward compared to other systems. The 9front.org web UI for Git is also a shell script using gitfs for data access.
• 53:00 - Q&A Highlights:
  • git checkout lacks a direct command in git-n (acknowledged as a potential man page improvement).
  • No plans to implement git blame natively, but contributions are welcome.
  • Work tree functionality (git worktree) is deemed easily implementable using Plan 9's file system binding and simple scripts.
  • File metadata (permissions, empty directories) is handled via mk tools or future git-n improvements.
  • The possibility of building Git on top of Venti as an object store is discussed as theoretically possible, though git-n's motivation was external Git compatibility.