@b0rk I also do a lot of git operations via Magit in emacs, which doesn't really fall into either category!

@b0rk does a TUI count?
I use a mix of CLI and gitui
https://github.com/extrawurst/gitui

@b0rk does magit count as a GUI?

@b0rk I use both regularly 😇

@b0rk Command line, reluctantly. I can't find a solid #Git GUI app for #Linux that works with private repos & doesn't have a subscription fee.

Back in my Mercurial days I used TortoiseHg & it was so nice.

@b0rk I answered GUI occasionally for the integration (fugitive) I use with my text editor: mostly difftool and staging chunks. Most of the rest is through command line.

@b0rk does git have a gui that keeps the semantics the same between command line and gui? My main issue with tools like sourcetree is e.g. when I’m trying to work git through a proxy and the settings are all called something different in source tree than `git config`

@b0rk I default to command line, but use Git GUI when I need to review larger diffs and stage/revert specific lines.

@b0rk I'd probably use a GUI more if I knew how to fetch and rebase onto upstream (not origin) in VS Code. I couldn't even find this workflow in the GitLens extension.

@b0rk The only aspect I use in a GUI are things built into the editor / ide like showing blame context in the gutter.

@b0rk I would say the Emacs "Magit" porcelain qualifies as a GUI, even though you can (and some people probably do) use it through a terminal emulator.

@b0rk
^all of the above, depends on
- Time of Day
- Month
- Workload
- Type of operation I have to perform
- Tiredness

@b0rk we do a most of our development on remotes, either via JupyterHub or VSCode over SSH. For the latter I forgot until checking the replies that it would count as a git GUI.

@b0rk

It's probably stockholm syndrome speaking, but I haven't found a git GUI that didn't confuse me even more than git's arcane command line does.

@b0rk
Some things (command line) were meant to be. 😉

@b0rk I tend to use both pretty regularly for different tasks.

@b0rk using tig as the “git gui” these days. Before that Sourcetree from Atlassian

@b0rk@social.jvns.ca I usually use the git integration built into my IDE (Eclipse or VSCode). But I also have some very useful git commands in my shell history that I occasionally use ctrl-r to find and execute as-is. I almost never use git cli other than these "historical" commands which I looked up once in the past.

@b0rk for me, VSCode is the GUI of choice, probably 50:50 split with the git CLI - plus occasional merge conflict resolution via the GH web UI

@b0rk I think I would prefer the GUI if there was a good one on Linux. I use gitg occasionally to look at changes, VS Code to commit and cli for everything else.

@b0rk There is yet another option - use Git via integration with the editor or IDE.

@b0rk Is Magit a GUI?
https://magit.vc/

@b0rk I'm all for the terminal on that matter. 🙌🏼
The GUI is just in VSCodium to look at the commit-graph and diffs 🤔

@b0rk I only use a GUI for one thing, which I do a lot and which the CLI is terrible at. Staging some (but not all) changed lines of a file.

@b0rk both occasionally because git isn’t really part of my job, but it is useful

@b0rk I do all operations using the commandline interface, but I do use gitk as a visualization tool at times (usually when doing a bunch of rebasing or merging and needing to figure out what goes where).

@b0rk Occasional VSCode GUI use to resolve merge conflicts or stage/unstage chunks, everything else CLI

@b0rk @Flyingmana hm... both for different things... to manage branches and look at diffs I like a GUI tool called Fork. To pull and stash I like to use the terminal.

@b0rk VSCode has GUI git functionality built right in, and that tends to be more than enough for my needs...

@b0rk The only GUI I use is my JetBrain IDE's, for two things:

* Code review before commit (with partial file selection just like "git add -p")
* Conflicts resolution

All the rest is done in CLI.

Though when I don't need to review the code (which can happen for small changes), I do check the diff in CLI for my review, and commit in CLI instead of my IDE.

All the rest, like rebasing, bisecting, log/graph, reflog, all this in CLI

@b0rk both, for different purposes!

@b0rk I'm using the command line with as little customisation as possible because I want to be able to use it on most computers, even those where I can't install new tools.

I would like to use a GUI more because it seems more intuitive. I think I could learn more about how git works if a GUI visualised it for me.

I'm mostly afraid to invest time learning a tool I can only use at home.

@b0rk I'm counting lazygit as a GUI.

It is very true to git concepts and makes annoying things like amending an old commit super easy.

I also use the command line a lot, often with two letter convenience wrappers.

@b0rk
gitk for going through the history.
Meld for complex diffs and merges.
Everything else I usually do on the command line.

(Not including the occasional web UI such as Gitlab)

@b0rk I mainly use Tower.app – I find it very helpful for interactively splitting up changes into separate commits and for a limited amount of rebasing. For more advanced rebasing, GitUp is quite nice. I also find Git Lens in VS Code helpful for seeing the blame for given lines directly in my editor (if that counts as a GUI).

@b0rk editor integration for basic stuff, CLI for anything more complicated

@b0rk I usually use magit in emacs, perhaps not a "GUI" per se, but it's certainly not cli

@b0rk I use the CLI when doing stuff in neovim and the GUI when doing stuff on PyCharm. Other use cases are rare, but usually also CLI. Thanks to watching a friend using it and reading what you post here, I now feel comfortable enough in the CLI :)

@b0rk hmmmmmm does magit within emacs count as CLI if I'm running it inside an SSH terminal..?

(I answered the poll meaningfully already, this is just out-loud rumination)

@b0rk Fork only for me!

@b0rk GUI is just superior for review and selective staging, for everything else CLI.

@b0rk

Mostly command line because I never know what a tool is going to do, but VS Code for diffs before I'm about to commit and when I get the case of a branch wrong on Windows (e.g., User/JLUsk/12345-Fix-the-thing, spot THAT error).

@b0rk I'm going to count Magit as a GUI, so I'll vote for both "command line, regularly" and "GUI, regularly".

I use Magit more often, but I do use the command line often enough to consider it regular. I also use gitk pretty regularly to visualize history.

@b0rk GUI for history/diff viewing and commiting, command line for anything everything else, esp. DAG altering commands such as merge, rebase, sync, etc.

thanks for the magit call-out :)

it's easy enough to consider it a "GUI" for poll purposes, tho. :)

@b0rk I’m an odd case but I use Visual Studio for Stage and the command line for Pull, Push, Commit, Clone. I use the process of staging items one by one to read through the diff before doing so to verify I didn’t leave a stray TODO or something in the code.

@b0rk i literally don't know how to use a gui for git :D i only know the cli

@b0rk both, regularly too. I've gotten really used to the CLI for most git stuff, but for fiddling with git history, merge conflicts and so on a good GUI (I mostly use the one in the JetBrains IDEs) is so much nicer to use than the CLI

@b0rk oops, I meant to multi-select. Add one vote for command line 90% of the time

@b0rk tig — a command TUI, is how i mostly use git

@b0rk On BSD and Linux I use the command line almost exclusively. On Windows I use VSCode most frequently but the command line also.

@b0rk I have found that I primarily use the command line, but I do like sublime-merge when I need to work with _part_ of a commit, or want to stage only part of the changes. I'm sure I can do that in the command line, but the visual indicator of what lines specifically I'm working on is helpful.

from the replies: the main things git command line users seem to prefer to use a GUI for are:

- staging complex changes (instead of `git add -p`)
- viewing history or complex diffs
- merge conflicts

@b0rk I use the vanilla vscode interface for adding/removing files to stage as I find the action of previewing then selecting individual files there much more mentally reliable than 'git add' ing otherwise arbitrary filenames. But I use the command line for simpler stuff like log (via aliases), merge, running through a rebase, etc.

@b0rk GUI for me is the git integrations in VS Code and Visual Studio. I mostly go to the command line when I'm getting an error that the UI is not communicating well, or if I'm trying to do something other than a basic checkout/push/pull.
GUI is great because I never have to manually set the upstream branch 🙄

@b0rk
this might aound backwards, but I prefer the command line because I'm never sure what GUIs are going to do, so they scare me. The GUIs I've tried (mostly just the ones baked into IDEs) use different language to describe what's happening, so I'm never confident I'm doing the right thing.

@b0rk I used to use command line only, but the commit message generator in IntelliJ's AI Assistant changed all that

@b0rk i use lazygit so.. TUI? ;p

@b0rk I use the command line for everything but two things: blame (for easy „blame parent commit“) and history browsing

@b0rk I occasionally use it inside my editor, which runs in text mode, but it felt like it was "GUI in spirit" for this poll.

@b0rk does GUI include TUIs?

@b0rk
I uses a git GUI (sublime merge) exclusively as a visualizer. I stage changes with VS code. Everything else (commit, rebase, pull etc) I do on the command line. I used to use git add -p a lot but I guess VS code's staging process is pretty good.

@b0rk I almost always use a gui (Fork) for making commits, terminal for ~everything else.

@b0rk I voted command line + GUI, with the latter being for my Magit usage (and I guess Github blame view). I use the command line for pull, rebase, log, diff, and many blame operations. I use Magit for committing things, especially selective commits, and thus for checking diffs before I commit and so on. (And some use of git-timemachine in Emacs to move back and forth through the history of a file to track things.)

But my git use is odd since I track and monitor a lot of upstream repos.

@b0rk I have used @fork_dev for the last 5 years or so and I can't be any happier

@b0rk

I work in IntelliJ, and it’s Git UI is so good (or I spent enough time to get used to it’s rough edges, too), that I feel much less productive on the CLI.

I wonder why IntelliJ users still use the git CLI, esp. for staging, writing commit messages, diffs and git blame.

But also branch operations and git log are good enough or even really good, depending on the use case. I totally recommend the interactive rebase UI!