Orto is an orthogonal data manager for Git.
It provides a clean and independent layer for managing data alongside your Git repositories, keeping your workflows modular and uncluttered.
Orto is designed to never modify your git repository in any way, so it can be used with any Git workflow and in any state, no matter how unmerged or broken the git repo is.
Unlike git stash, which keeps temporary changes inside the .git internals, Orto acts as a safe stash. It lets you save a snapshot of your uncommitted changes outside of the repository, manage them orthogonally, and bring them back when you need them. This keeps your repository history and stash list uncluttered while giving you fine-grained control over your work-in-progress.
Unlike git bundle, Orto's output system is designed for flexibility, human readability, archival and to be used even without having access to git. Multiple output formats will be supported, and, due to Orto's architecture, packfile/bundle writers can be developed for Orto.
Orto will also include a restore phase, allowing you to selectively bring your data back to the state it was in when you saved it.
By design, Orto is able to archive your .git directory along with your changes, for those cases where the repository may be in a potentially inconsistent or vulnerable state.
- Written in Go for speed and portability
- Orthogonal design: manage data without polluting your Git history
- Lightweight integration with existing Git workflows
- Several output options (zip, tar.bz2, raw directories, patch, separate git repo, packfiles, etc.)
- Archive/backup git repo along with data
- Include files that git ignores
- Encryption to safely store untracked files with credentials
- Simple setup and usage
- Include a list of the changes and state of the working copy/index/etc.
- Cloning files rather than copying them when supported (e.g., APFS, Btrfs.) Thanks Chris Hulbert for the idea!
| Component | Progress |
|---|---|
| Find Phase - Builds a catalog of the current state of the git repo and the filesystem | 🟩🟩🟩🟨🟥 75% |
| Diff Phase - Compares working tree with Git objects, index, etc. | 🟩🟩🟨🟥🟥 50% |
| Write Phase - Outputs changes to destination format | 🟩🟨🟥🟥🟥 30% |
| Restore Phase - Selectively applies saved changes | ⬜⬜⬜⬜⬜ 0% |
-
Startup
- Implement CLI
- Implement error and help screen
- Add symlink support: symlinks appear as blobs but with a different mode. Also check symlinks on the filesystem.
- Configuration file?
- Allow relative directories in the input
-
Find phase
- Decide what to do with empty dirs
- Support arbitrary commits
- More ignore/include file option
-
Diff phase
- Consider using inodes/etc to check if a file is the same / deduplicate hard links
-
Write phase
- Save diffs - localized and with full content per file, single file per change set
- Implement output file compression
- Separate outputs for index and working tree, etc
- Where the OS and filesystem allows it, clone files rather than copying them:
- Stop before running out of space
- Encryption
-
Testing
- Test in Windows and Linux
- More automated tests
- Git-based test suite
- Determine minimum git and go versions
- Test files with unicode and other special characters
-
Overall
- Figure out if there's been a case change, think about how to handle it in different OSs/file systems.
- Process and include staged (index) changes
- Save remote, branch and commit info (i.e., where the information came from)
- Allow find/diff/write to stream rather than executing in sequence.
- Error recovery where it makes sense
- Test unmerged files
- Set up CI pipeline
- Set up automatic linter and formatter
- Restore phase
- Git LFS
- Finish submodule support
- Backup Hooks & Configs
-
Questions
- Interactive mode?
- Consider separating the phases into independent programs
- Allow output to non-empty directory?
- Allow output to a parent or child directory in some cases?
-
Technical information