Christoph
b00e3e5c18
Add credential-aware submodule operations and a command to checkout a specific
tag or commit in a submodule without staging the parent repository.
- Backend (src-tauri):
- Export checkout_submodule_revision and implement checkout_revision which
validates tag vs commit inputs, verifies refs locally, and checks out the
submodule in detached mode without modifying the parent's index.
- Add optional username/password parameters to add_submodule and submodule_action
flows. Implement submodule_git to call run_git_authenticated when credentials
are supplied and classify auth failures by prefixing errors with "AUTH_FAILED:".
- Wire authenticated variants (operate_authenticated, add_authenticated) and
update fetch/update actions to use credentials where needed.
- Add unit tests covering authenticated submodule commands, auth failure
classification, and checkout-by-tag/commit behavior.
- Frontend:
- App.svelte: introduce credential prompt flow (withSubmoduleCredentials,
submit/cancel handlers), surface credential dialog on auth failures, and
wire credentialed calls for initialize/add/update/fetch operations. Hook up
checkoutSubmoduleRevision and listTags to the submodule dialog.
- SubmoduleDialog.svelte: add UI for selecting destination folder, loading
tags and checking out revisions; expose fetch action.
- CredentialDialog.svelte: include "submodule" action and adjust labels.
- Docs:
- README: document "Change commit or tag" and "Fetch tags & commits" behaviors.
The commit focuses only on enabling credentialed submodule interactions and
safe local checkouts of tags/commits; no other git behavior changes are made.
156 lines
4.5 KiB
Markdown
156 lines
4.5 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.
|
|
Use **Change commit or tag** to select a local tag or enter a commit hash;
|
|
**Fetch tags & commits** downloads remote revisions using the submodule login.
|
|
Checking out a revision leaves the parent index unchanged until you stage its reference.
|
|
|
|
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.
|
|
|