Skip to content

Commit 5aa45fb

Browse files
committed
Readme tweaks
1 parent bbd63f4 commit 5aa45fb

File tree

1 file changed

+73
-21
lines changed

1 file changed

+73
-21
lines changed

README.md

Lines changed: 73 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,23 @@
11
# git-remote-sqlite
22

3-
- [Latest release](https://github.com/chrislloyd/git-remote-sqlite/releases/latest)
4-
- [Latest changes](https://github.com/chrislloyd/git-remote-sqlite/commits/main)
5-
- [Source code](https://github.com/chrislloyd/git-remote-sqlite)
3+
[Latest release](https://github.com/chrislloyd/git-remote-sqlite/releases/latest) | [Changes](https://github.com/chrislloyd/git-remote-sqlite/commits/main) | [Source](https://github.com/chrislloyd/git-remote-sqlite)
64

75
---
86

9-
**git-remote-sqlite(1)** is a [Git protocol helper](https://git-scm.com/docs/gitremote-helpers) that helps you store a Git repository in a [SQLite](https://www.sqlite.org) database. Why would you want to do this?
7+
**git-remote-sqlite** is a [Git protocol helper](https://git-scm.com/docs/gitremote-helpers) that helps you store a Git repository in a [SQLite](https://www.sqlite.org) database. Why would you want to do this?
108

11-
1. **Simple Git hosting**. Hosting git repositories typically involves using a third-party forge like GitHub or Sourcehut. These provide value by automating hosting NFS mounts and providing a web interface for collaboration.
12-
2. **Self-contained application bundle**. It serves as both a Git repository hosting alternative and enables Lisp/Smalltalk-style development images where code and its runtime state coexist.
13-
3. **(Advanced) More control over automation**. Leveraging Git hooks lets you transactionally automate tasks like migrations.
14-
4. **(Advanced) Build your own workflows**. An application can be built that is self-updating - you don't need to rely on pull-requests or emails etc. to update your application, you can easily build updating itself into your application.
9+
1. **Simple Git hosting**. Hosting git repositories typically involves using a third-party forge like [GitHub](https://github.com) or [Sourcehut](https://sourcehut.org). These primarily provide value by handling the storage, networking, and access control complexity of hosting Git repositories. At a smaller scale, **git-remote-sqlite** (combined with other tools like [Litestream](https://litestream.io)) may be cheaper and practically easy enough to use.
10+
2. **Self-contained application bundle**. While **git-remote-sqlite** isn't as powerful as Lisp/Smalltalk-style images, it does allow an application's data to be distributed alongside its code. What can you do with this? I don't know but it sounds cool!
11+
3. **(Advanced) More control over workflows**. Leveraging Git hooks lets you transactionally automate code changes. Think Erlang/OTP's `code_change/3` but more generic.
1512

1613
## Installation
1714

18-
1. Download the latest release for your platform:
15+
1. Prerequisites
16+
17+
* [Git](https://git-scm.com) >= 1.6.6
18+
* [SQLite](https://sqlite.org) >= 3.0.0
19+
20+
2. Download the latest release for your platform:
1921

2022
```bash
2123
# macOS
@@ -25,25 +27,25 @@
2527
curl -L https://github.com/chrislloyd/git-remote-sqlite/releases/latest/download/git-remote-sqlite-linux -o git-remote-sqlite
2628
```
2729

28-
2. Make the binary executable:
30+
3. Make the binary executable:
2931

3032
```bash
3133
chmod +x git-remote-sqlite
3234
```
3335

34-
3. Move the binary to your `$PATH`:
36+
4. Move the binary to your `$PATH`:
3537

3638
```bash
3739
sudo mv git-remote-sqlite /usr/local/bin/
3840
```
3941

40-
4. The installation is complete. The binary functions as both a standalone command and as a Git remote helper.
42+
5. The installation is complete. The binary functions as both a standalone command and as a Git remote helper.
4143

4244
## Basic Usage
4345

4446
### 1. Push to/pull from the database
4547

46-
Push your code to the SQLite database:
48+
When `git-remote-sqlite` is in your $PATH, you can push your code to a local SQLite database. If it doesn't exist, it'll be created:
4749

4850
```bash
4951
git push sqlite://myapp.db main
@@ -55,9 +57,11 @@ Pull it back:
5557
git pull sqlite://myapp.db main
5658
```
5759

60+
All done! Fancy.
61+
5862
### 2. Configure Repository Settings
5963

60-
You can configure server-side git settings stored in the SQLite database:
64+
You can configure server-side git settings. These don't currently affect any behavior.
6165

6266
```bash
6367
# Set configuration variables (similar to editing server-side git config)
@@ -74,13 +78,61 @@ git-remote-sqlite config myapp.db --get receive.denyDeletes
7478
git-remote-sqlite config myapp.db --unset receive.denyDeletes
7579
```
7680

77-
These settings are stored in the `git_config` table and affect how git operations are processed when interacting with the SQLite repository.
81+
## How it works
82+
83+
**git-remote-sqlite** stores Git objects (commits, trees, blobs) as rows in SQLite tables. When you push to `sqlite://myapp.db`, Git objects are inserted into the database. When you pull, they're read back out.
84+
85+
The [database schema](docs/schema.md) includes:
86+
87+
- `git_objects` - stores all Git objects with their SHA, type, and data
88+
- `git_refs` - tracks branches and tags
89+
- `git_symbolic_refs` - handles HEAD and other symbolic references
90+
91+
Since it's just a SQLite database, you can query your repository with SQL, back it up with standard tools, or even replicate it with Litestream.
92+
93+
## FAQ
94+
95+
### Why not just use a bare Git repository?
96+
97+
Bare repos work great for traditional hosting, but SQLite gives you:
98+
- Queryable data - find large objects, analyze commit patterns, or build
99+
custom workflows with SQL
100+
- Single-file deployment - one `.db` file instead of a directory tree
101+
- Replication options - tools like Litestream can continuously replicate
102+
SQLite to S3
103+
104+
### How does performance compare to regular Git?
105+
106+
For small-to-medium repositories, performance is comparable. The SQLite
107+
overhead is minimal for most operations. However:
108+
- Large repositories with thousands of objects may be slower
109+
- Pack files aren't implemented yet, so storage is less efficient
110+
- Clone operations might be slower than optimized Git servers
111+
112+
**git-remote-sqlite** is currently proitizing simplicity and trying new stuff over raw performance.
113+
114+
### Can I use this with existing Git workflows?
115+
116+
Yes! **git-remote-sqlite** is a standard Git remote helper. You can:
117+
- Push/pull between SQLite and regular Git repos
118+
- Use it alongside other remotes (GitHub, GitLab, etc.)
119+
- Apply standard Git workflows (branches, merges, rebases)
120+
121+
### Is the database format stable?
122+
123+
The schema is documented in [docs/schema.md](docs/schema.md). While I may
124+
add tables (like pack support), I'll try not to break existing tables without an automatic migration plan.
125+
126+
### What about security?
78127

128+
**git-remote-sqlite** provides no authentication or access control - it's
129+
designed for local use or trusted environments. For remote access, you'd need
130+
to add your own security layer or use SQLite's built-in encryption
131+
extensions.
79132

80-
## Development Status
133+
## TODO
81134

82-
Currently implemented:
83-
- [x] Configuration management (set, get, list, unset)
84-
- [x] Git remote helper protocol (push/pull functionality)
85-
- [ ] Pack file management (tables defined but not yet implemented)
86-
- [ ] Git hooks
135+
- [ ] Git hook support
136+
- [ ] Pack-file management
137+
- [ ] Full support for protocol commands
138+
- [ ] Performance profiling for large repos

0 commit comments

Comments
 (0)