The cli because it is consistent everywhere and has all fearures
this post was submitted on 07 Aug 2025
79 points (98.8% liked)
Programming
22147 readers
9 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
Jah, mein fearures
The only thing I'm missing in the CLI is easy picking and choosing which change to include in a commit on a more fine grained basis than files. I sometimes have a changed file and the changes fix different issues and thus should get separate commits but with the CLI I can't easily select the changes to be staged. At least not AFAIK.
Edit: Richards law of posting something wrong to get fast correct answers seems to stay true, even on lemmy. Thanks for teaching me something today <3
You can via git add -i foo.bar
I believe the only issue with that is that it can only go by hunks. If your changes are sufficiently far away, you can select them separately. But if you change one function that should be in patch a, and another function 5 lines down that should be in patch b, I think you're screwed
That being said, this is all from memory, so don't quote me on it
I usually use git add -p to selectively stage hunks. But in git add -i I think running the patch command does the same thing to get into patch mode.
If patch mode shows you a hunk, and you only want some of the lines you can press s to split into smaller hunks. Then you'll be prompted whether to add each smaller hunk separately.
If you want to stage a change that is on the same line as a change you don't want to stage, or on an adjacent line, then you need to use e to edit the hunk. Git stages whatever changes are left when you're done editing. The file in the working tree on disk is unchanged.
CLI first here too, for the same reason.
I'm not above using an editor plugin if it's simple and reliable and right there waiting, like VSCodium.
load more comments
(1 replies)
TortoiseGit.
Through settings, I move the Show Log to the top context menu level, and it's my entry point to every Git operation.
I see a history tree to see and immediately understand commit and branch relationships and states. I can commit, show changes, diff, rebase interactive or not, push, fetch, switch, create branches and tags, squash and split commits, commit chunk-wise through "restet after commit", … And everything from a repo overview.
/edit: To add; other clients I tried never reached what I want from a UI/GUI, never reached TortoiseGit. Including IDE integrations where I'm already in the IDE; I prefer the separate better TortoiseGit.
GitButler is interesting for it's different approach, but when I tried it out the git auth didn't remember my key password. (Since trying out jj I found out it may have been due to disabled OpenSSH Service.)
I have a love-hate relationship with it. Due to work reasons I'm more familiar than I want to be with tortoiseSVN, and the git version is similar enough to feel at home. But that's also it's biggest downfall: it does a lot of things the "SVN way" despite being a git client. The workflow can be kinda made to work, but it always feels like it's not a native git tool, because it isn't. I would go so far as to say that it encouragedrl bad habits on git, especially for those used to tortoiseSVN.
load more comments
(1 replies)
load more comments
(1 replies)
Fork on windows, SourceGit on Linux, both have a similar UI layout to SourceTree, but are much faster/snappier.
I really like having a clear overview of the commit history, branches and current local state. I haven't figured out yet how to get such an "at a glance" overview in the CLI.
For advanced stuff the CLI is still very convenient.
Have to take a look at Fork (annoying name to Google I image). Sourcetree can be quite sluggish and downright annoying on macOS.
Ditto on the CLI having its pro's and cons
load more comments
(1 replies)
load more comments
(2 replies)
I use plain old git for the same reasons already mentioned, but magit is the gold standard.
I'm a big fan of tig for visualizing the graph and looking over history (then I don't need to leave the terminal, and it's snappier, in my experience, than most full-GUI programs like Sourcetree), but for actual Git commands, I like the CLI
Fugitive, the vim / neovim plugin. It does everything the CLI does, but uses vim interfaces very effectively to enhance the experience. For example it's quite good for selectively staging changes from a file. I also like the option to open a buffer with the version of a file from any specified commit.
I also tried neogit which aims to port magit to neovim. I didn't like it as much. Partly because as far as I could tell at the time it lacked features compared to fugitive. But also because it seemed to want me to do everything through UIs in its own custom windows. Fugitive is integrated more thoroughly into vim via command mode, and special buffers.
I mostly use the cli, but also Sublime Merge. It makes some things really convenient (like committing only some lines in a changed file), and looking at diffs is snappy too.
Just fyi, you can add only a few lines of a changed file on the cli too using git add -p
cli and meld for mergetool
Yeah, meld is nice.
It's what they used at my job when I started, it does the job, and I've gotten used to it. 🤷♂️
load more comments
(3 replies)
I use Sourcetree for routine stuff, though I occasionally have to hit the command line when shit gets real.
I use GitHub Desktop on Mac and PC. It works fine with local repos, too.
Whatever's built into pycharm or vscode for looking at diffs. Command line for push pull squash etc
CLI, nvimdiff 90% of the time. If I’m on a windows workstation, I might end up using git extensions GUI as it helps me visualize what’s happening a little better sometimes.
For professional use I’ve heard good things about SmartGit, unfortunately my work refused to buy me a license and the trial period wasn’t long enough for me to really form an opinion.
Work suggests to use SourceTree but it is way too sluggish.
These days I use git CLI for most things, and VSCode to review changes and submit PRs. Of course this also assumes you use a decent shell with git support, like Oh-My-Posh or similar, so it is always clear what you are working on.
Mainly the official git CLI for controlling branches and sub modules, and sometimes the GitHub CLI if quickly checking out a pull request from a forked repo.
Also use the source control tab in VSCode rather often, as it's really convenient to review and stage individual line changes from its diff view, and writing commit messages with a spell check extension.
If it's a big diff or merge conflict, I'll break out the big guns like Meld, which has better visualizations for comparing file trees and directories.
About a decade ago, I used to use SmartGit, then tried GitKraken when that came around, but never really use much of the bells and whistles and wasn't keen on subscription pricing. Especially as the UX for GitHub and other code hosting platforms online have matured.
CLI for me. I do use the GitLens plugin in vs code but only so I can see commit info inline. I never commit anything from vs code.
I like Kaleidoscope (v3) for diffs but not for merging. I could probably use any graphical difftool for this purpose but it’s what I’m used to.
FYI, VSCode can now natively show commit info inline, no GitLens extension required:
https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_git-blame
load more comments
(1 replies)