Glance: a Git GUI for Windows built on gix

[onmcore]

I'm the solo dev behind Glance, a Git GUI focused on staying fast in huge repos (millions of commits).
Under the hood it uses gix for Git operations - really appreciate the work you all put into it.
(Glance itself is closed source, but wanted to share how gix is powering it under the hood.)

My day job is C++ game dev, this was my first real Rust project (with Tauri for the UI).
Happy to share more about how I'm using gix if useful, and open to feedback.

https://github.com/onmcore/glance-releases

[Sebastian Thiel (Byron)]

Thanks a lot for sharing! It's exciting to see, particularly that it has a lot of features that gitoxide doesn't provide. Built-in git-lfs is definitely on my list as well.

I am watching releases now so one day I can try it out natively on macOS :).

Cool stuff

• engine per feature, also a good indicator for me to see where gix is lacking.
• - great it just finds the local Git
• helping to update Git itself is great!
• multi-window mode, nice!
• The memory footprint is really low!
• - the reflog presented as a timeline, innovative even.
• - simple and straightforward, great!
• branch information is great!
• built in terminal!!
• cloning with progress is great (powered by gix, and that's what it was made for :))

Puzzles

• cherry-pick you can totally implement in gix, I wonder what's missing for you.
• merge should probably be usable in gix already, so I wonder what's missing.
• rebasing is similar
• it's strange to see reset available in gix, to me it's one of the harder things to do (right)
• strange that these settings aren't picked up - maybe something about not seeing Git installation settings?
• in theory, this is something that is configured in Git, so I wonder why this needs to be separately configured.
• While a matter of taste, the Logo does not work for me:

Notes

• It's great to have the notion of long-running processes (i.e. fetch), but it's still early days (i.e. what changed after a fetch?)
• having worktree support is good, but this is where I see a lot of potential for improvement (UX). Having a window per worktree for instance would be nice.
• creating worktress is way too cumbersome and I'd wish for more of worktrunk's elegance. It should be super easy to do worktrees nowadays.
• I'd want a setting to turn off animations
• it would be so nice to have multi-file diff views (i.e. see all changes in a branch, or a commit)
• The tree structure of uncommitted files wasn't obvious to me. I like that it also allows to commit. Also: one can change the tree view to something more obvious.
• gix could probably use facilities to apply diffs, and maybe to revert them.
• stashing, also on my list
• checkout - definitely also on my short-list even, at least to provide more primitives while working towards reset.
• worktree and submodule creation is also something gix should learn at some point, looking forward to make that happen one day.

[Sebastian Thiel (Byron)]

Special Bread (@special-bread) Should definitely take a look as well :). Maybe you could also post a link to your Git client here, it seems I don't have it anymore.

[onmcore]

Thanks for taking the time to write this up — really appreciated.

On the gix questions: Glance has a per-feature engine selector (gix / libgit2 / CLI), and merge / cherry-pick / rebase currently run on the CLI path while reset is on gix. That's a historical ordering more than a judgment about gix — moving the rest over is on the list. Diff apply/revert, stashing, and checkout primitives landing in gix would all be things I'd adopt.

core.autocrlf / core.eol not being picked up is a bug, not a design choice — thanks for catching it. I'll look at how global/system config is being resolved.

Everything else you wrote is going straight onto my list. Feedback this specific and this honest is rare, and it's exactly what I need at this stage — thank you. I'll do my best to act on it.

[Special Bread (special-bread)]

I have been summoned!

https://gitcherrytree.com/

is the link you wanted :>

I just did a quick skim and have random thoughts:
Generally speaking here i use a mixture of libgit2 and gix (git cherry tree doesnt need a git CLI to be installed). I use gix for git status on windows, as well as checking out files of all flavours, and writing commits.

You need to have an implementation for checking out a tree efficiently, and then most git operations are just rearranging trees, then checking out a tree once at the end. This is more efficient and safer too since you have fewer chances for an external file watcher like cargo-watch or unity or something else putting stuff in while an operation is running.

Fortunately gix provides enough primitives that you can assemble a very fast tree checkout indeed! Same for committing. Gix can be made to go really really fast at committing files, ive committed the entire linux repo before (90k files) in one commit and it took a couple of minutes to hash and thats it. If the files are already hash it does the same in 3-4 seconds, but thats not a fair measurement, but i guess its to say that most of the time its just hashing.

Also gix is used to power stuff you wouldnt expect like the undo/redo anything system, that isnt reflogs so it can also undo discarded files you never committed :>

Git cherry tree also has full lfs support. but that does require git lfs to be installed for the filters. And then I use gix filter stack to check out files as normal. There are additional shenanigans needed to identify pointers safely and you can do more tricks there, but thats the gist of it, hope that helps.

For me the main consideration to use gix or not is blast radius. im pretty careful to use it for places where i need the speed or features, and otherwise default to libgit2, where that has been tried and tested for many years, so I worry about making sure i never break stuff.

With regards to cherry pick and rebase, squash/merge/split/reword and all that - they dont want you to know this but everything is just cherry picking with extra steps :>

With regards to ui, i actually moved away from tauri to Iced for myself, it has more reliable frame control which i find pleasing. Also, thats not released yet so on the site you will find the tauri version I believe. Making this post made me realise how long its been since a release! The client really has moved on a lot since then, i need to get my act together :<

Perhaps you would too if you want to load very large diffs. I have a reddit post on that (below), and im actually working on a redo of my site which will include that, and more, as blog posts that describe how to load 1 million line diffs, do git status on massive repos, and so on, you can shame me into publishing sooner :>

https://www.reddit.com/r/rust/comments/1q3q1pw/drawing_a_million_lines_of_text_with_rust_and/

I think overall gix is very powerful indeed, git cherry tree uses it in one way or another for most operations, and I can see it replacing libgit2 entirely. But I have found myself hesitant to do so since its extremely important code, and so I only switch it over by necessity and always with heaps of testing. Something something thanks to byron for making it exist? :>

Also you caught me at exactly the wrong time but i shall go on holiday and so will disappear for a couple of weeks, but feel free to ask questions i guess :>

[Sebastian Thiel (Byron)]

Thanks so much for sharing, I was eating it up!

Fortunately gix provides enough primitives that you can assemble a very fast tree checkout indeed! Same for committing. Gix can be made to go really really fast at committing files, ive committed the entire linux repo before (90k files) in one commit and it took a couple of minutes to hash and thats it. If the files are already hash it does the same in 3-4 seconds, but thats not a fair measurement, but i guess its to say that most of the time its just hashing.

All this seems pretty slow, but I guess 90K new files for hashing really wants to run in parallel and it should saturate the disk easily.
Creating a new commit once the hashes are known in 3-4s is also slow, and I'd think that maybe it's spending all this time writing loose objects? If so, you can use in-memory objects, and write them back yourself with multiple threads, once again saturating disk and/or CPU (compression).

Git cherry tree also has full lfs support. but that does require git lfs to be installed for the filters. And then I use gix filter stack to check out files as normal. There are additional shenanigans needed to identify pointers safely and you can do more tricks there, but thats the gist of it, hope that helps.

It's strange anything has to be done with pointers manually, after all, a pointer in Git is converted by the filter pipeline, so the caller never sees it. When diffing these, this also runs under the hood with diff-filters on top, so again pointers shouldn't have to be known by the app. What am I missing?

For me the main consideration to use gix or not is blast radius. im pretty careful to use it for places where i need the speed or features, and otherwise default to libgit2, where that has been tried and tested for many years, so I worry about making sure i never break stuff.

That's fair, and it's something I want to change. Will be working on stable gix towards the end of the year.

With regards to cherry pick and rebase, squash/merge/split/reword and all that - they dont want you to know this but everything is just cherry picking with extra steps :>

And cherry-picking is gix merge :D. There now is gix merge tree @ @ $(stg id review2) --message "review" --update-head to allow running merges/cherry-picks by hand to do cherry-picks that Git won't allow you to do but which have purpose nonetheless. Anyway, I digress, the key message was: merging is very powerful :D.

With regards to ui, i actually moved away from tauri to Iced for myself, it has more reliable frame control which i find pleasing.

That is super interesting! Just took a quick look and saw iced is imperative! So I am very much looking forward to compare both and see how different they feel.

Perhaps you would too if you want to load very large diffs. I have a reddit post on that (below), and im actually working on a redo of my site which will include that, and more, as blog posts that describe how to load 1 million line diffs, do git status on massive repos, and so on, you can shame me into publishing sooner :>

I am looking forward to seeing this on Reddit 🤩!

https://www.reddit.com/r/rust/comments/1q3q1pw/drawing_a_million_lines_of_text_with_rust_and/

A great teaser for what's to come! And somehow I missed it, and enjoyed reading it all the more. What I learn is to really avoid browser based frontends when trying to do a fast CLI - ultimately it needs perfect control to be fast, and even if fast isn't needed, it's so easy to destroy the webview and make it completely unresponsive.

Something something thanks to byron for making it exist? :>

So now it's my personal goal to help you make the switch! Well played… :D. And thanks :).
You can help me by creating an issue like this that contains all the things you need at least (while I find interesting to see what you already use, possibly with notes on how to make these better - incremental diffing seems like something you'd like and not much would be missing I think).