this post was submitted on 24 Sep 2024
566 points (99.1% liked)
Programming
17486 readers
246 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 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Other than untracking tracked files, I see nothing in this graphic that isn't easy to do with a gui. That might even be easy to do but it is something I do in the cli. Can I get some examples?
I would also argue that the common/basic stuff is 99% of what I do with git. And for this I can't fathom why people would think the cli is better. Like logging and diffing is just so much easier when I can just scroll and click as opposed to having to do a log command, scroll, then remember the hashes, and then write the command. This is something instantly available to me in a gui.
Don't get me wrong, if the cli is better for you more power to you. We moved from p4 to git and I did this almost exclusively in the cli so I could use scripts more easily. And sometimes I watch beginners use the gui and I have to bite my tongue because I know it would be faster in the cli.
But, especially for a beginner, i strongly recommend a gui.
Interactive rebase? There's no GUI that actually does that well, if at all. And it's a massive part of my daily workflow.
The CLI is far, far more powerful and has many features that GUIs do not.
It's also scriptable. For example, I often like to see just the commits I've made that diverge from master, along with the files changed in each. This can be accomplished with
git log --oneline --stat --name-status origin/master..HEAD
. What's more, since this is just a CLI command, I can very easily make a keybind in vim to execute the command and stick it's output into a split window. This lets me use git as a navigation tool as I can then very quickly jump to files that I've changed in some recent commit.This is all using a standard, uniform interface without mucking around with IDE plugin settings (if they even can do such a thing). I have many, many other examples of scripting with it, such as loading side-by-side diffs for all files in the worktree against some particular commit (defaulting to master) in vim in a tabpage-per-file, which I often use to review all of my changes before making a commit.
There are cases where instead of
origin/master..HEAD
you may want to use@{upstream}..HEAD
instead to compare with the upstream of your current branch. It's unfortunately quite unknown.Click to view diffs is super ergonomic; on the other hand, I actually have a story about the Git CLI trumping the GUI (spoiler: reflog).
In high school we had gotten the funding to build a robot, and one of the adults in charge -- guy was brilliant -- was using GitHub Desktop to conduct a feature merge with the student who served as team lead. The thing was, he was used to older codebases, so all of his experience was with CVS instead of Git -- so when the two slightly messed up the git merge, they discussed recloning everything instead of wasting time plumbing the error (relevant xkcd).
That was one of the earliest times I had the cajones to walk up to a superior and say "No, you're doing this totally wrong. You don't have to do that."
He looked at me and nodded. "What would you do instead?"
"Reflog."
"Reflog? I've never heard of it before. Can you show us?"
I hopped onto the laptop and clicked around GitHub Desktop, but couldn't manage to find any buttons related to reflog... so I went straight to cmd.exe instead.
"Done. We can continue rebasing."
And after that, the advisor complimented me for using the command line tool!
"Lots of GUI apps are just limited frontends to the real meat and potatoes, the command line. Nice job!"
I felt like a wizard! And so I became the team's Git-inator.
edit: pruned story
I didnt say the GUI was not easy for the common stuff. But I think the CLI is also easy for the common stuff so there is not much advantage other than a bit of a learning curve with the CLI. But the big thing that GUIs make harder is automation of common things. For instance, when I want to create a PR I like to rebase to the latest upstream. In a GUI that is a bunch of button clicks. With the cli I just
<CTRL+R>pus
and that will autocomplete togit pull --rebase=interactive --autostash && git push && gh pr create --web
and I am landed in a web browser ready to review and submit my PR. Doing the same thing in a GUI takes a lot longer with a lot more clicking.And that is a very common command for me.
Never found that to be a big issue. Most of the time when you want a diff you want to diff local changes or staged changes which is simply
git diff
andgit diff --staged
neither of those are hard or any real easier in the GUI (especially with bash history). For diffing specific commits I dont find that hard either justgit log --oneline
and find the commits (and you can use grep to filter things out easily as well here) - typically does not require scrolling at all. Thengit diff <copy paste>..<copy paste>
. In the GUIs you are often scrolling through commits you want to select at some point so I dont see how that saves you any real time here. I would not say the CLI or GUI is vastly easier in this case. And even in this case it is rare to need to do. Far more often is just branches which on a decent shell can be tab completed for convenience.This is why I prefer the CLI for common stuff. It is just faster.
And that is where I disagree. I think beginners should spend some time learning the tools they will need to use. IMO the CLI is critical for developers to learn and the sooner the better. So many things a vastly easier with the CLI than GUIs and a lot of stuff is near impossible with GUIs. Automation being a big one. I have not seen a good CI system that is GUI focused that you never need to know the cli for. Or when you have a repetitive task then it is quicker to write a quick script and run that then doing the same thing over and over in the GUI. Repeating actions is also easier in the CLI. All of these apply to more than just git as well.
I have seen so many beginners start with GUIs that don't really understand what they are doing in git. And quite often break things and then just delete and recreate the repo and manually make their changes again. I find people that never bother with the CLI always hit a ceiling quite quickly in terms of their ability and productivity.
The only real thing that makes the CLI worst is that it has a steeper learning curve. Once you are over that hill I find it to be vastly better for more situations or at least not practically any worst than a GUI equivalent. So that hill is one well worth climbing.
I can always use a GUI if I really needed to. But those that only know the GUI will have a very hard time on the CLI when they need to - which is required far more often than the other way round.