Comment by imiric
3 months ago
Am I the only one who simply doesn't mind Git's CLI?
Sure, it's rough around the edges, but I know those edges well. I sometimes do need to look up how to do something, but those cases are rare. Over the years I've accumulated about a dozen shell aliases and a modest `.gitconfig`, and along with a couple of helper tools[1][2], I can do 90% of what I need Git for in seconds. I truly don't need a fancy TUI, GUI, or any wrappers around Git. Git itself is fine.
I tried Magit a few times, and even though Emacs is my main editor, I couldn't get used to it. It forces the user into doing things the "Magit way", and I'd rather not.
I don't understand the push to replace Git's porcelain with something shinier. If, and when, a better VCS comes along that truly feels like the next step forward, I'll give it a try. In the meantime, Git does the job I need.
I can use the CLI, but magit is mostly CLI on steroids. All the information you could have accessed through the cli is quickly available, and they are active objects, meaning subsequent commands will take that into account. Any mutation is also available through quick keybindings as well.
The one thing that I truly like about Magit, and the builtin vc-mode, is that I can focus for a couple of hours on coding, then quickly create a serie of commits to capture that work. Like doing line art after sketching. I like when administrative work (filing patches under commits) is isolated from creative work (solving problems and designing practical solutions).
No - unless you took away my gitconfig, which is pretty big at this point. Though I guess that's mostly a time-saver. Even so, I've found most of the GUI tools to be confusing because it's hard to tell what they're actually doing under the hood.
I do use sublime merge at times though now - it's nice for [un]staging individual lines and for looking at some diffs. I also like git-foresta[1] more than log sometimes. I'll have to check out scmpuff - it should be easier than going through a patch add.
[1]: https://github.com/takaaki-kasai/git-foresta
I do not mind the Git CLI, and I just carry around my alises. I also built a tool to make it even more powerful and integrate with issue trackers: https://pypi.org/project/gibr/
I completely agree, and I would add that in just about any dev role beyond being a junior it's so common to need to work efficiently without much of a dev environment anyway.
There's just no point in fighting this battle. I will admit it's sometimes nice to have fancy tools, but they're just that. I don't get the need to make a hobby out of it when there's so much other stuff to do.
There is a new VCS that is a step forward (while being compatible with git). It’s called jujutsu.
Yeah, I disagree.
I've read the Jujutsu documentation and a lot of praises for it, and its most compelling feature is a simpler UI compared to Git. There have been other VCS tools with arguably better UIs and feature sets than Git (Mercurial, Fossil), and yet they haven't gained traction, for better or worse. The only reason jj is having more momentum is because of its compatibility with Git, which was a smart decision by its developers.
A better UI is not something I would consider a next step for a VCS tool. I can do that myself with my shell and small helper tools. Whereas features like semantic and binary diffing would be compelling generational improvements over Git. I know these can technically be tacked on to Git itself, but a VCS built for them would be able to do things Git simply can't. These are just two I can think of, but a next generation tool would be evident without requiring much explanation. Just like DVCSs were over the previous generation of tools.
jj is not just a simpler UI. Its rebase is fundamentally more powerful than git, it has things like the operation log, first class conflicts, etc… that git doesn’t have.
> Am I the only one who simply doesn't mind Git's CLI?
No, but by definition, Git's CLI doesn't scale for complex use cases. No one would voluntarily use the CLI for doing a complex 3-way merge if they could avoid it.
Due to the complexity of Git's interface, it's too easy to make a mistake using the CLI. I get we don't use most of the options most of the time, but when you need them, they're not exactly discoverable.
git help commit is over 4,000 words!
> No, but by definition, Git's CLI doesn't scale for complex use cases.
How so? A CLI is where you run commands and things happen. Sometimes those things can be "complex", whatever your definition of that may be.
> No one would voluntarily use the CLI for doing a complex 3-way merge if they could avoid it.
And nobody does...? A manual merge is done in an editor or a standalone tool, not the CLI.
> Due to the complexity of Git's interface, it's too easy to make a mistake using the CLI.
Well, Git's UI can be intimidating for a newcomer, but once they're acquainted with the dozen or so commands they might need every day, they can define aliases for them, and mistakes are no more likely than with any TUI or GUI wrapper. Git by design gives full control to the user, so mistakes can happen, but this is no different than with most Linux tools. And if safety is a concern, then whatever hand holding a TUI or GUI does, the same can be implemented in a shell script.
> git commit alone has 40+ options
So? You would prefer less options? Less commands? Less flexibility?
Just look up what you need to do and how to do it, and stick it in an alias. Now you have a clean command purpose built for your use case, and you can ignore anything you don't use.
Or, you can use a fancy TUI/GUI wrapper that "simplifies" this interface for you, and then when you need to do something that the wrapper UI doesn't allow you to do, have to fall back to the original UI. I'd rather familiarize myself with the original UI, create the aliases and helpers that work best for my workflow, and not have to depend on someone else's idea of how I should use Git, or any other tool.