> Out of curiosity, what specific tasks are easier using a GUI?
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.
You can't just blindly run git commands without being aware of current state. Some beginners or people with less technical roles try to use git by blindly running 3 commands they memorized, but that easily results in a mess or situation where it's necessary to call a more experienced colleague to fix their local copy.
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.
As a former darcs user who was won over by and still uses git-gui to this day, reviewing and staging/reverting changes hunk-by-hunk/line-by-line, and subsequently referring back to what I've left unstaged.
`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).
At least with magit, I can look at the entire diff, then highlight specific lines, and stage those fairly easily. `git commit --patch` gives youhunks, but if you need to break those hunks up it's a couple extra steps.
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) ?
With Magit I've found that you can just be faster. Nicer autocomplete functionality, quick access to flags when doing operations, being able to point your cursor at a commit and say "cherry pick _this_ please".
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".
