Christoph
c3762ae7a3
Allow pulling repositories with unrelated commit histories when the user explicitly opts in. The pull argument construction was refactored and branch resolution made more robust so the backend can include the --allow-unrelated-histories flag when requested. - Extract pull argument logic and add support for allowing unrelated histories. - Prompt users in the UI to confirm merging separate histories and retry pull. - Restyle and improve the update toast UI for better layout and responsiveness.
Gitty
A lightweight, modern Git client built with Tauri.
Fast, simple, and designed for developers who want a clean Git experience without unnecessary complexity.
✨ 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
- 🎨 Modern and intuitive UI
📸 Preview
Screenshots coming soon.
🛠️ 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:
yay -S gitty-desktop
To install the prebuilt native Arch package instead of compiling from source:
yay -S gitty-desktop-bin
Or build the AUR package manually:
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:
gitty.exe --repo "D:\Projects\ExistingRepo"
Clone a remote into an exact local target folder and open it immediately:
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.
Development
Start the complete desktop application in development mode with:
npm run tauri:dev
The development launcher preserves normal proxy settings. If a sandboxed
development terminal injects the non-routing 127.0.0.1:9 proxy or its
blocking SSH placeholder, those values are removed only for the Tauri child
process so Git remotes and Git LFS remain testable in the debug application.
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.
SigNoz telemetry
After the user opts in, Gitty sends privacy-filtered product events and technical errors as OTLP/HTTP JSON logs. Every Git/Tauri command is also captured as a trace span with its command name, duration and success state, but without command arguments or results. CPU utilization and resident memory usage of the Gitty process are sampled every 30 seconds and exported as OpenTelemetry gauges. The default endpoints are https://telemetry.cbsk-tech.de/v1/logs, https://telemetry.cbsk-tech.de/v1/traces, and https://telemetry.cbsk-tech.de/v1/metrics.
The SigNoz reverse proxy must forward all three paths to the Collector's OTLP/HTTP receiver (normally port 4318). For development or a separate collector hostname, set GITTY_OTLP_LOGS_ENDPOINT, GITTY_OTLP_TRACES_ENDPOINT, and GITTY_OTLP_METRICS_ENDPOINT to the full signal URLs before starting Gitty.
Telemetry is non-blocking, bounded, disabled until consent is stored, and never includes repository paths, remote URLs, branch names, commit messages, diffs, file names, credentials, source code, URLs, or email addresses.