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).

> 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        |

I will always take faster tools, but sometimes things are good enough.

> 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.

https://github.com/extrawurst/gitui/issues/32

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.

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.

https://marketplace.visualstudio.com/items?itemName=trunkflo...

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)

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.

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.

It's fully compatible with git.

What I used to need a GUI for now I can easily do with jj.

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).

0: https://github.com/NeogitOrg/neogit

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.

No other git ui program has ever come close to how naturally I feel using a context menu based system like tortoisegit.

For me one of the biggest benefits of using a git GUI is always visible current state: what you have checked out, what are the recent commit, what's the state of other branches, do i have any unmodified files. All of it in front of my eyes, not requiring any additional input (beside alt tab for switching to the graphical git client). Not that you couldn't get the same information from git CLI, but the question is how often would you do that, and would you check all of it each time.

But I often perform many of the actual changes in terminal using the default git CLI client.

In this sense I consider shell integration based version control clients bad, as they require using context menu to open the information windows and it's a step that can be skipped since most of the other actions will likely be in the same context menu. Thus you endup with similar situation as CLI clients - information is available but you have to actively request it.

Next step to consider is TUI vs GUI. I find that that often due to constraints of fixed character grid and limited graphical elements TUI can be less dense. Every box and separator line means a wasted row/column. Two boxes side by side - that's two wasted rows. Everything being monospace font - additional wasted space. Single font size for everything - makes it impossible to use smaller size font for short less important text. You can set a very small text size in terminal, but it hurts overall readability of the TUI and all other work you do in terminal, and it doesn't change the fact that TUI was designed with limited available space in mind thus you only get slightly longer text but no additional information. On the other hand TUI will more likely have a very efficient keyboard only navigation and single key actions. GitUI and many Norton commander inspired TUI file managers like FAR and MC are good examples of this.

Personally, I really like being able to stage/unstage blocks of code or even individual lines in a GUI, if I've done some refactoring and added new logic at the same time, but want those in separate commits.

Aside from that, I really like working in a GUI, looking at the commit graphs, easily switching between any number of branches and merges being a right click away.

I actually ended up paying for GitKraken because it also makes managing multiple accounts (personal vs work) as easy as choosing what I want from a drop-down, as well as includes workspace functionality to group multiple repos together.

Before than, using SourceTree or Git Cola was also decent. Just feels like one of those things that are convenient with a GUI, except I enjoy standalone tools for that more than most IDE integrations.

Less futzing around with copying around IDs and the such. I still need to know how to do most everything with git itself, but because I know that, I can rely on magit to just make it quicker for me to "do the thing".

`git add --patch` (the way I usually do it) is good enough when you’re adding parts and know what to do in the future. Recently, though, I’ve been using lazygit's ability to create a partial patch from a commit and effectively split the commit into two or more parts. This lets me take a larger set of commits and turn it into something that is easier to review (it’s sort of a hyper interactive rebase where you can add or remove lines, files, or trees into each patch).

I wouldn't even think of doing this without lazygit (and if gitui is ever at par with lazygit for this, I might switch).

GUI stuff is not necessarily about enabling new workflows so much as making workflows _very fast_ and less error prone. In theory at least.

you might mean "perusing" (one of the many vocabulary words, like "quaff", "wield", and "comestible", that I learned from Nethack when I was younger) ?

> Various Package Managers

Quite a long list at the right side, but... no Debian?

I'd think that the user base of Debian would be larger than of some of the other distros listed (edit: changed wording here) there, so ...what up? why?

This is not the first time I've witnessed this exact situation during the past half a year or so. Is this some weird conspiracy among Rust devs (joke!), or is it the Rust tooling that makes integrating into the apt ecosystem a challenge, or what?

I mean, if I really insisted on getting that tool installed I see there's a binary, and if there was not, I'd find a way, but I'm genuinely curious. This seems counterintuitive, so there must be a reason? no?

I think the reason is that its built using rust, which moves fast and breaks things, very un-Debian.

This tool requires rust 0.65 which is old by rust standards. The latest debian stable has rust 0.63.

The Rust Project itself had put a lot of work into making sure that Rust and Rust-using programs could get into Debian by working with Debian folks to address issues.

I suspect that you've run into an anecdotal pattern, but I'm not sure that it is more than that.

Debian packaging is notoriously difficult and has a very steep learning curve if you want to do it "the right way" aka using Debian's arcane collection of debhelper Perl scripts.

On top of that, there was/is/IDK a lengthy period of debate in Debian on how to deal with third party library managers in general (PHP Composer and especially NodeJS started the debate), which scared people off for good.

The funny ones are the ones that put "Written in Rust" in the features section.

Written in Go/Rust is definitely a feature for something like this.

Generally speaking Rust programs are fast, memory-efficient and of high quality.

I'm certainly not saying this is always the case, or that it's impossible in other languages, but I am definitely going to take a closer look if something new and interesting prominently says it was built with Rust.