Get the top HN stories in your inbox every day.
badsectoracula
Lio
Yep, supplementing keyboard shortcuts with terminal mouse support is really useful.
In Vim the things I still use a trackpad/mouse for are scrolling and resizing windows. There's definitely no reason you can't have both even over SSH.
Would be a great addition here too.
jonwest
I see that lazygit is listed as inspiration for this project. As a lazygit user myself I'd be curious as to what was lacking from lazygit to warrant an entirely new project, as I've found it to be incredibly useful.
rrr_oh_man
I cannot judge whether the methodology makes sense, but the numbers seem quite impressive for my manager brain:
> Readme.md
For a RustBerlin meetup presentation I compared lazygit, tig and gitui by
parsing the entire Linux git repository (which contains over 900k commits):
| | Time | Memory (GB) | Binary (MB) | Freezes | Crashes |
| ------- | ---------- | ----------- | ----------- | --------- | --------- |
| gitui | 24 s | 0.17 | 1.4 | No | No |
| lazygit | 57 s | 2.6 | 16 | Yes | Sometimes |
| tig | 4 m 20 s | 1.3 | 0.6 | Sometimes | No |fbdab103
On the other hand, I do not work on a repository nearly the size of Linux. If you evaluate performance on a more modest project, is there a meaningfully human speed difference?
I will always take faster tools, but sometimes things are good enough.
vrmiguel
I found the memory gains to be more enticing than the performance improvements
NERD_ALERT
I’ve been a daily lazygit user for years and tried this out a few months ago. Seems like a case of rewriting a near perfect tool in Rust just for the sake of doing it. From what I remember this project didn’t have any features that aren’t present in lazygit but was lacking some that are.
srott
I was missing interactive rebase, as it is missing from libgit2
piersolenski
I prefer the UI, especially with Vim key support, although LazyGit feels like it has slightly more features.
zuhsetaqi
He says it in the README:
> 2. Motivation
> I do most of my git work in a terminal but I frequently found myself using git GUIs for some use-cases like: index, commit, diff, stash, blame and log.
> Unfortunately popular git GUIs all fail on giant repositories or become unresponsive and unusable.
pama
"Unfortunately popular git GUIs all fail on giant repositories or become unresponsive and unusable." I have only witnessed that in magit (or pyright) when I have super deep directory trees (say a wide dataset collection) not yet in .gitignore and then git status takes forever in cmdline or in magit. But I don't think that there is a difference between a GUI or TUI or cmdline use of git in that case. Do other interfaces to git fail in more spectacular ways than git itself?
rtpg
Magit's failure mode is downstream of it (I believe) pulling in diff information on the status page. When I've had this problem, doing `git status` on the command line has always been more or less instant.
There is something inevitable about needing time to display a lot of information. But I think magit is eager in some places that lead to extremely costly magit workflows when the raw git workflow would be much faster.
eddieh
Yeah, I never do a big merge in magit. I just use the git CLI for those.
lolinder
It's surprising to me if so. IntelliJ's git UI is more than fast enough, and it's written in Java and embedded in the IDE. An external git UI shouldn't have any issues.
mschuster91
IntelliJ is only performant due to its indices of pretty much everything. That is its true magic.
In contrast, the Git CLI and most if not all other UIs have zero sorts of caching and have to start from scratch for everything.
lolinder
That seems like a problem that could and should be solved.
lolive
IntelliJ has, imho, the most comprehensive & visual diff management UI. That thing alone discards any competitor [once again, imho].
undefined
dang
Related:
GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - Sept 2022 (90 comments)
Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - Dec 2020 (1 comment)
abdullahkhalids
Has anyone made a click-and-drag UI for git? Where you can do operations on branches by just dragging them around.
memco
My favorite got GUI is Fork: https://git-fork.com/ It supports drag and drop for several operations including merge, rebase, and stage/unstage (and probably more).
ap-andersson
Also love Fork and my whole team uses it at work aswell. We work on Windows and wanted a better GUI app since we use git from a GUI 90% of the time. We used to use Sourcetree years back and it never worked well. Tried a few alternatives but in my mind Fork was the clear winner. The UI is clear, snappy and works as you expect it would. I wish they had a higher price for companies (to make sure they can survive, since they use lifetime licensing...) and possibility to buy licenses that can be assigned and reassigned. I had to fight the company to buy the license since you always buy it for an individual, which does not fit how companies usually buy software or subscriptions.
stsrki
I also use Fork and find it the fastest and easiest git GUI. And I tried so many GUIs in the past. One thing that works well in Fork is submodules, which are almost non-existent in other GUIs. And the UI is really fast to respond.
On a side note, regarding the licensing. As a software vendor selling to enterprises, I always struggle with finding this kind of information. Would you be willing to briefly explain how large enterprises usually buy software or subscriptions? It would help me/us so much.
namtab00
did you evaluate GitExtensions?
BerislavLopac
I'm not sure what's kind of of operations could be done by "dragging branches around", but in GitKraken
drak0n1c
GitKraken has a dropdown menu that appears whenever you drag and drop if it involves two elements (ie merge, rebase, create GitHub PR), as well as right click if you're operating on one element (ie creating branch/tag here, reset soft/hard). Double left-click to checkout a branch. There are big buttons at the top for fetch/pull/push, and when staging a commit there's a clean and focused view for choosing which hunks to stage. Basically all needed operations can be initiated with minimal mouse actions, and anything destructive has a confirmation.
BerislavLopac
Thank you, that's exactly what I wanted to write, but my phone hiccuped in the middle of writing that comment and I wasn't sure if it was posted at all. :rolleyes:
charrondev
I use GitHub desktop for basic operations and the CLI for anything complicated. It’s a pretty minimal git client but it does have some drag and drag (for cherry picking commits.
Yasuraka
I did stumble upon an extension where it's one of the advertised features, but haven't tested it
https://marketplace.visualstudio.com/items?itemName=trunkflo...
kentosi
Even after 10 years, SourceTree is still my goto when I need UI click-and-drag.
eddd-ddde
Not exactly git, but meta's version of mercurial (I think it's called sapling) has this, you can rebase really easily your commits.
danielhep
Git Tower for Mac works great for this
nurgasemetey
Sublime Merge
zmmmmm
I try all these tools, but somehow always end up with some key feature missing or not working how I want. I guess it must be extremely personal. But somehow I always end up back at tig. With GitUI I couldn't find a good display of branching structure eg: in the Log view. I would love one of these that could do a good rebase-aware display of branching.
glitchc
This looks great, I'll give it a whirl.
I'm hoping GitExtensions gets ported to a native Linux application one day. I've tried dozens of UIs and nothing else seems to compare.
Spunkie
Similarly, tortoisegit is the only windows application I miss on a daily basis since switching to Linux.
No other git ui program has ever come close to how naturally I feel using a context menu based system like tortoisegit.
namtab00
It always amazes me how few devs know. GitExtensions.
Only other git UI that's comes close to it is Tortoise, of which I've only used the hg variant a while back.
nichos
Gitex is fantastic. I'm still using the 2x mono version on Linux.
divbzero
GitUI could be also named GiTUI.
Ancapistani
This looks very much like the Noevim plugin I began using about a month ago: neogit[0].
The keybindings were a bit rough, and it took me about an hour of use before I was really comfortable with the overall workflow. Once I was, though, I’ve found it to be much faster than my previous workflow (suspending neovim and using git directly in the shell).
wruza
One of my concerns with ui tools is that they often hide the actual command from the user, so it’s hard to reason about what’s wrong afterwards and how to avoid it in the future. E.g. some tools could add pretty opinionated flags that are incompatible with the rest of workflow done in a regular cli.
Idk if it applies to this one. Just thought that this feedback could be interesting for tools from this category.
namtab00
That's why (on Windows) I use and love GitExtensions.
It always shows complete commands it issues, and you can fully view the complete log.
Sleaker
What's the main benefit of using a GUI with git for people? For me it's usually just the ease of not needing to know a commit hash to perform a rebase against after a merge, but I generally just do these ops from within an IDEs builtin git support and everything else is command line. Do others find a huge benefit from GUIs?
aulin
In magit I find invaluable being able to stage chunk by chunk. It enables a whole different workflow, where I review my own code staging it step by step.
Also being able to navigate blame history inside the editor is pretty cool.
No idea about other GUIs, if I have to get out the editor to use git I might just use the command line.
Sleaker
For workflow reviews I tend to just push to GitHub and then use it's review diff when making PRs to catch anything I may have missed (typos usually)
Ah I do use git blame sometimes but it's builtin to the ide so I get it while editing code live. I guess this is the biggest difference I have with not wanting a gitgui, any of those ops I feel like I can get with my ide.
aulin
Sure, magit is in some sense "getting it with the ide".
Not sure how advanced is blame in other editors, it's not just blame annotation, is being able to navigate the history of a line just jumping from one change to the previous and back. It's incredibly helpful with large code bases to understand how some code evolved and why it's implemented like that.
Another great magit feature is being able to open a file from any git revision. Like you want to copy some line from a file that's being long removed you can just call magit-find-file on a revision that still has it, open it in buffer, copy what you want etc.
cdcarter
`git add -p`
zdimension
Working often with multi branch projects across repos (forks and upstream), using GitKraken simply makes me more productive. I don't think anymore about how I'm gonna merge or rebase stuff, it makes everything more intuitive. I still use the CLI for advanced stuff that the GUI doesn't handle, but for day to day operation, it's a panacea
eddd-ddde
Lately I've been using this: https://martinvonz.github.io/jj/v0.10.0/
It's fully compatible with git.
What I used to need a GUI for now I can easily do with jj.
StimDeck
I am perfectly comfortable with CLI git, certainly when measured against my peers, but I still prefer the visual tree, context menus, command palette, etc. I like to right click and edit commit messages. I like to copy branch names. I like to do visual three way merges. I can understand what went wrong more quickly when a PR has unexpected changes. I can see what branches are in origin at a glance. I don’t have to remember the name or hash of anything.
spixy
- (un)staging only parts of files instead of whole files
- seeing full content of a branch without checkouting
- seeing diffs between local/remote/stash branches instantly just by Ctrl + mouse click
- automatic stash+reapply local changes when pulling or checkouting branch
- easy using multiple ssh keys (due to multiple remotes)
- easy show/hide parts of tree in (a nice rendered) tree
- just one mouse click to show commit in github (and probably other sites)
etc.
most of them could be done with CLI but it would just be suffering for me
jethronethro
"[T]he comfort of a git GUI but right in your terminal"
Get the top HN stories in your inbox every day.
> Fast and intuitive keyboard only control
I'm sure the author had nice intentions, but the very first thing i tried when i installed this (it is from openSUSE's repository so it might not be the latest version) was to resize the xterm window as it was too small and then tried to click and drag the edge of the file tree window hoping to make it smaller as i wanted most of the visible area to be the diff (and the files in the tree have small names, meaning most of the file tree window was wasted space). Turned out it was not possible.
The help shown with H didn't have any keys for that either, meaning it may not be possible even with the keyboard, though IMO this is one of the cases where even if it was possible via keyboard, being able to resize with the mouse is vastly easier and faster (keyboard resize is still nice for the cases where a mouse is not available though, like using the program via a broken ssh setup).