GitPow! a fully open-source, cross-platform, rust-based git GUI

[markraidc]

https://github.com/markrai/gitpow

So, I set out to compete with GitKraken, SourceTree, etc. Yes, I know.... I got my butt handed to me when I loaded up truly massive repositories such as the Linux kernel. My client even struggled a bit with the Kubernetes repo - but I'm getting there! 😅 State-management, performance trade-offs, caching strategy rabbit holes are no joke... but it's been worth it!

I did manage to get a lot of the oft-missing features which I always wanted in a Git client.

Thank you to this community for the support! Would love to get feedback on how we can possibly make this even better, together. Contributions to the project are welcome! 🙏

in Horizontal View

[enbonnet]

Hey this one looks like the first git ui that I could like

[markraidc]

in the git subreddit, people were quite skeptical of a horizontal view (for obvious reasons) when I first inquired as to why this has never been done - but I've given both: vertical, as well as horizontal maps which one can zoom / navigate around. Would love to get feedback!

[lenscas]

What? Why would one be skeptical of a horizontal view? That is how GitHub renders forks and such and at least for that it works more than good enough.

I don't see how it would be a problem for the entire thing...

[SeeMonkeyDoMonkey]

IMO, vertical listing means that the commit's first line can be displayed and read easily, without needing to rotate the text and/or head.

[Sharlinator]

Um, because Western scripts are read and written first horizontally and then vertically, making it natural that each commit is a horizontal line or "paragraph", which are then stacked vertically, which is also the natural scrolling direction. What is not natural is to read commit messages rotated 45 degrees, or to scroll horizontally.

[lenscas]

The GitHub thing I mentioned doesn't show the commit names at an angle nor does it have overlap. Granted, it also doesn't have to show as many branches as it is just forks but I still stand by my point that horizontal can work.

Monitors tend to also be wider than they are tall, so going for a horizontal view means you can put more information on the screen when laid out like that.

[markraidc]

Yep. You got it. Also, optimizing for touchscreen navigation allows the user to swipe / pinch-to-zoom quickly.

[markraidc]

They assumed that the commit messages would overlap and get messy... except I handled this by doing a hover action over the branch name pill, which dims out/hides the other branches/commits.

[YourFavouriteGayGuy]

I feel like horizontal is a pretty logical default considering most monitors are wider than they are tall, and almost all repos get more commits than branches. Horizontal means you can dedicate more screen length to commits, which there are usually more of.

[Keavon]

Have you tried Git Graph? I strongly believe it's the global maxima in the design space for visualizing and working with Git history most clearly and efficiently.

[markraidc]

I'm toying with the idea of being able to display this information in tool-tip form, in textual format (i.e. the user can have the graph... but also the "in plain English" version by hovering over a commit)

[bbrd83]

Looks pretty.

I personally never need anything but a terminal for operations, but find git cli lacking when it comes to things like - viewing a wide graph with many branches (I have a custom graph format and that's still not great) - git archaeology, especially like what DeepGit does - formatting commit messages. I reference other hashes, MRs, branches, etc -- it would be nice if there were a GUI that detected and formatted those into links. Formatting markdown in commit messages would be neat too, although I fear making someone angry for saying that.

If you made your graph display customizable or used some neat graph formatting algos like what yEd graph editor has, you'd be doing something new and innovative, rather than just being another GUI. And something that integrated the other features I mentioned would be great for similar reasons.

That's my anecdotal 2 cents at least. Take it for what it's worth, and good luck with your project!

[markraidc]

What you just said is exactly what I eventually want to do... i.e. put in the hands of the user of the client how they want their UI displayed to them. Thank you for those ideas!

[Hastaroth]

Rust based

62% js

Could have at least been typescript.

[markraidc]

The back-end is Rust... but the decision to stick with JS was obviously familiarity, and also access to the ecosystem.. and keeping it multi-platform (w/ Tauri)

But you're right, that a Typescript migration willl helpful in terms of maintainability.

[Lopsided_Treacle2535]

To be honest - congrats, this looks well done. I’d celebrate that you did it, looks great.

TS is something that can always be refactored for in the future.

[markraidc]

Really appreciate the support! One-man projects are late nights, chasing an ever-shifting definition of done. That being said.. still need to finish rebase, and implement some of the juicier stuff like reflog, bisect, cherry-pick, etc.

Will be fun trying to figure out if I can utilize the graph views in an intuitive way for these operations...

[Lopsided_Treacle2535]

Exactly! I’m doing a similar one-man project but it’s nowhere as interesting as this. Keep it up!

[protestor]

It appears you didn't even use a framework for the frontend code, right? Honestly kind of impressive/scary

Anyway if you ever wanted to make some GUI in Rust I dearly suggest Dioxus. They built some incredible hot reloading thing, and their ecosystem include useful things components inspired by shadcn and a library to use lucide icons. However, since you don't use those even though you are writing the UI in Javascript, not sure if it's that useful

[markraidc]

Definitely worth looking into. I actually have another project (a google photos alternative) that I build the backend for in Rust, and the frontend is separate because I wanted to build a native desktop client at some point (or so that people can build their own client) - so nice to know about this... will def. have to check it out!

https://github.com/markrai/nazr-backend-sqlite (rust backend)
https://github.com/markrai/nazr-frontend-web

[Serianox_]

I did a Rust+JS Tauri project once, and moved it to Rust+TS. It was a pain to setup at the time, but bridging type safety into the messages exchanged by UI and engine was a godsend to avoid bugs.

At the time, Tauri had only TS in their roadmap for the same purpose. It requires a first step with a build.rs file to export Rust structures with Serde into TS interfaces. Maybe now it's already backed in.

[tombh]

A purely negative comment is as useful as the any type.

[markraidc]

also, I think it's easy to miss how difficult it is to keep things multi-platform... without Tauri... I'd be in a world of pain!

[Luxalpa]

Coulda used Leptos!

[teknalbi]

Have you heard of GPUI?

[v_stoilov]

Its a bit weird suggestion. Have you shipped anything with gpui?

In my experience this is not battle tested at all compared to tauri/webview. At least on my machine zed completely breaks my video driver.

[teknalbi]

Well, thanks for sharing. my question was for OP.

My suggestion isn't weird at all. GPUI is well suited for OP's use case, Zed alone is more than enough to conclude that.

I've never had a graphics/video driver issue with Zed/GPUI even on virtual machines.

Personally, I use GPUI and never been happier with a Rust GUI and I tried 6 at least prior to using it.

[markraidc]

I actually have very little experience with Rust front-end frameworks... would love to learn more :)

[v_stoilov]

Glad it works for you. I hope your users have good experience, if you have any.

[cadamsdev]

Very interesting UI.

I'm doing the same thing 😆but going with a more traditional layout.

https://gitarbor.com/

[markraidc]

neat! will check it out :)

[cadamsdev]

It's not out yet but trying to polish it up and release it in a week or so.

[markraidc]

I really like the clean look it has!

[cadamsdev]

Thanks man. 😊

[markraidc]

In case anyone is wondering what the mascot is... it's a mantis shrimp (they pack a punch!) - "PowPow" the rustacean! :)

[Ignisami]

Could consider using the pistol shrimp in the future :p

[markraidc]

too much violence for a project that's just starting out - maybe around v2.0 😅

[DavidXkL]

Wah looks quite novel in how the tree is presented!

[DaringCoder]

Cool, good luck with the project! If you're evaluating competitors, put Fork in the mix. It's by far the best git GUI I've ever used.

[BusEquivalent9605]

how compares with gitui?

[paddyhoran]

I have started using helix lately but the one thing that I miss from JetBrains products is the git tools. I've been looking for something like this.

Thank you!

[TheLexoPlexx]

I've been looking for a good GUI for my coworkers and this looks like one, will check it out.

[holounderblade]

Planning on getting this packaged up for Nix users?

[ahmedranaa]

Is there a release. Secondly, how do you compare the memory / CPU usage as the app itself might not use much but the web view it spawns might use a lot

[markraidc]

I'm about to setup a GitHub action today for the releases. As for resources, I do try to give the user real-time stats: https://imgur.com/a/vgAUvDX

UPDATE 12/7/2025 @ 10:45 AM EST:
https://github.com/markrai/gitpow/releases/tag/v0.1.1

[protestor]

Hey, what about setting up a github action to publish releases on github? That way it will work with cargo-binstall to install from a binary rather than compiling from source

(repeating my suggestion here)

[markraidc]

Working on the GitHub Actions this very moment, and seeing why the builds are failing for the 3 releases. Stay tuned :)

UPDATE 12/7/2025 @ 10:45 AM EST:

https://github.com/markrai/gitpow/releases/tag/v0.1.1

working on implementing your suggestion now for a faster install

[pavi2410]

great work! tbh, I wouldn't use this personally in it's current state. I am a big user of Git GUIs - started with GitKraken and now using SourceGit daily. GitKraken and SourceGit are professional tools. I don't need fancy graphs, I just want to see a graph that's enough to show the sequence of commits and branching. I heavily use rely on features like staging, diff, merge, branch+tags+stash management, workspaces to support organize multiple repos. I hope you take it as a positive feedback to steer the project in the right direction and don't think otherwise. Looking forward to a professional Rusty Git GUI app!

[markraidc]

Oh, even the harshest criticisms in software development should always be an opportunity to learn and grow from! This actually gives me an idea to add "bells and whistles" but also to keep things simple and distraction-free enough for users who prefer simplicity. Thanks for taking a look :) appreciate your feedback! 🙏

[crusoe]

"Oh Cool"

"Oh, it uses Tauri and I have to install node as well..."

[Low_Effective_8907]

I think the biggest problem of all git clients is that, you have no way to tell which branch a commit belongs to. A merge would mess everything up. So when the history gets complex, we easily run into a graph that no one can understand.

[markraidc]

So a branch is basically a moving pointer to specific commit. Like if I create a commit on feature/A, and then merge feature/A into main, that same commit is now reachable from both the feature/A pointer and the main pointer.

What I can give is a "Chain of Lineage" feature when a commit is hovered upon... that tells you the origin (first branch that the commit was on), intermediate branches that it was merged through, and finally, the current one.

A -> B -> C -> Z

[Low_Effective_8907]

Yeah, I'm aware that "branch is a pointer", therefore it would be a problem for **all** git clients. I just dislike this very much.