Christoph
66c85321ea
Add a new backend module to manage Git submodules (list, initialize/update, stage, sync, add) and expose Tauri commands (list_submodules, submodule_action, add_submodule). The implementation enforces safe relative paths, a maximum nesting depth, and guards (dirty/conflicted checks and initialization/no-op semantics) to avoid unsafe operations. Refactor clone logic to a testable run_git_clone_command and enable automatic initialization of submodules during clone by passing --recurse-submodules. Also disallow certain submodule-related custom clone flags so callers cannot override this behaviour. Update README with a Submodules section and add frontend components and types to surface submodule UI (dialogs, toolbar badge). Unit tests were added for submodule discovery, initialization/update semantics, and recursive clone behavior.
153 lines
4.3 KiB
Markdown
153 lines
4.3 KiB
Markdown
<div align="center">
|
|
|
|
<img src="public/splash-icon.png" alt="Gitty Logo" width="360">
|
|
|
|
# Gitty
|
|
|
|
**A lightweight, modern Git client built with Tauri.**
|
|
|
|
Fast, simple, and designed for developers who want a clean Git experience without unnecessary complexity.
|
|
|
|
</div>
|
|
|
|
---
|
|
|
|
## ✨ Features
|
|
|
|
- 🚀 Fast native performance
|
|
- 🌿 Branch management
|
|
- 📝 Commit history
|
|
- 🔄 Pull, Push & Fetch
|
|
- 🔀 Merge & Rebase
|
|
- 📦 Repository management
|
|
- ☁️ GitHub, GitLab, Azure DevOps, and Gitea integrations
|
|
- 🗄️ Git LFS detection, tracking and object management
|
|
- 🧩 Submodule management, including nested repositories
|
|
- 🎨 Modern and intuitive UI
|
|
|
|
---
|
|
|
|
## Submodules
|
|
|
|
Cloning automatically downloads and initializes submodules, including nested
|
|
submodules, at their recorded commits. The Submodules toolbar badge counts modules
|
|
that still need initialization. After a successful pull, Gitty offers to initialize
|
|
missing modules; choosing **Later** keeps the badge visible.
|
|
|
|
Open a repository and select **Submodules** in the repository toolbar. The dialog
|
|
shows each submodule's recorded commit (from its parent's index), checked-out
|
|
commit, and local changes. You can add a submodule, initialize it, check out its
|
|
recorded commit, stage a changed reference, synchronize its URL from `.gitmodules`,
|
|
or open it as a repository tab. Nested submodules are included by default.
|
|
|
|
Checking out a recorded commit is blocked when the submodule has local changes;
|
|
commit or stash them in that repository first. Adding a submodule stages
|
|
`.gitmodules` and the new reference. Commit these changes in the parent repository.
|
|
Network operations use your configured Git credential helpers or SSH credentials.
|
|
|
|
## 📸 Preview
|
|
|
|
> Screenshots comes later.
|
|
|
|
---
|
|
|
|
## 🛠️ Built With
|
|
|
|
- **Tauri**
|
|
- **Rust**
|
|
- **Svelte**
|
|
|
|
---
|
|
|
|
## 🚧 Status
|
|
|
|
Gitty is currently under active development.
|
|
|
|
Contributions, feedback and feature requests are always welcome!
|
|
|
|
---
|
|
|
|
## 📄 License
|
|
|
|
MIT License
|
|
|
|
---
|
|
|
|
## Arch Linux
|
|
|
|
Install Gitty from the AUR with an AUR helper:
|
|
|
|
```bash
|
|
yay -S gitty-desktop
|
|
```
|
|
|
|
To install the prebuilt native Arch package instead of compiling from source:
|
|
|
|
```bash
|
|
yay -S gitty-desktop-bin
|
|
```
|
|
|
|
Or build the AUR package manually:
|
|
|
|
```bash
|
|
git clone https://aur.archlinux.org/gitty-desktop.git
|
|
cd gitty-desktop
|
|
makepkg -si
|
|
```
|
|
|
|
The source recipe downloads the public Gitea release archive and builds Gitty.
|
|
The `-bin` recipe repackages the native `.pkg.tar.zst` release artifact. The
|
|
release pipeline updates both packages' versions, checksums, and `.SRCINFO`
|
|
files.
|
|
|
|
---
|
|
|
|
## Command line
|
|
|
|
Open an existing repository when Gitty starts:
|
|
|
|
```text
|
|
gitty.exe --repo "D:\Projects\ExistingRepo"
|
|
```
|
|
|
|
Clone a remote into an exact local target folder and open it immediately:
|
|
|
|
```text
|
|
gitty.exe --clone "https://example.com/team/project.git" "D:\Projects\Project"
|
|
gitty clone "git@example.com:team/project.git" "D:\Projects\Project"
|
|
```
|
|
|
|
`--clone=<REMOTE>` is also accepted. Relative target paths are resolved from
|
|
the current working directory. Clone and repository requests are forwarded to
|
|
the running window when Gitty is already open.
|
|
|
|
---
|
|
|
|
## Git hosting integrations
|
|
|
|
Gitty connects to GitHub, GitLab.com, GitLab Self-Managed, Azure DevOps, and
|
|
Gitea from **Settings → Integrations**. Each connection uses a personal access
|
|
token that is stored in the operating system keychain instead of application
|
|
settings. Azure DevOps can manage multiple organizations with separate URLs,
|
|
usernames, and tokens.
|
|
|
|
After enabling a connection, open **Clone → Integrations** to load the
|
|
repositories available to that account. Repositories are sorted
|
|
alphabetically and can be filtered, refreshed, selected, and cloned directly
|
|
with the stored credentials.
|
|
|
|
---
|
|
|
|
|
|
## Git LFS
|
|
|
|
Gitty bundles the `git-lfs` executable in its desktop installers and checks it
|
|
at runtime before offering LFS actions. Arch packages also declare `git-lfs` as
|
|
a dependency so Git hooks and command-line workflows outside Gitty use the same
|
|
extension. The repository toolbar exposes LFS setup, tracked patterns, object
|
|
downloads, and safe cache pruning. After every successful clone or pull, Gitty
|
|
detects LFS usage and automatically downloads the required LFS objects with the
|
|
same remote and credentials, so no second pull is needed. Fresh clones also get
|
|
repository-local LFS filters and the pre-push hook before they are opened.
|
|
|