Comment by magicalhippo | Hacker News Reader

Comment by magicalhippo | Hacker News Reader

Parent Full thread

> I feel like I'm the minority suggesting the cli as a good way to use git.

I used Mercurial a lot before trying Git for the first time, the projects then switched to Git.

With Mercurial I felt right at home with the command line. Everything was simple and made sense, and I seldom had to consult the documentation after a short time learning it. I never felt the need for a GUI, or that it would improve things.

With Git it was the complete opposite. Nothing made sense at the command line. I had to do web searches for just about everything I did, either to figure out what arcane set of switches to use or to make sure I didn't fuck things up. After a short while I gave up and found a GUI, which made Git much, much better to use.

Perhaps things have improved somewhat, I hear they've cleaned up the command line options a bit. But looking at the manual[1] its clearly still far from Mercurial-level of usability[2].

[1]: https://git-scm.com/docs/git-reset#Documentation/git-reset.t...

[2]: https://book.mercurial-scm.org/read/undo.html#rolling-back-a...

Things aren't any better. I've given up on the Git command line. I'm never going to remember the various flags-vs-unintuitively-named commands.

TortoiseGit is ugly and sucks, but the only time I've had to drop to the command line is when I need to look for the intersection or disjoint commits

Let's not trash TortoiseGit. Sven has put so much work and polish into it. Ugly? Maybe you just hate Win32 UIs? That's ok.

TortoiseGit has many great features, including ways to compare anything you can think of.

So far it's been the best free Git client I've used, but I miss TortoiseHg's interface.

I'm still not over Mercurial losing the DVCS wars.

Git has a reputation for having one of the most confusing CLIs ever. However, it's probably better to decide what operations you want to do and work from there to find out the commands needed. That obviates the need to learn so many commands and switches - for me, at least. My training material was also designed like that. My students use them like cheat-sheets until they get familiar enough.

The thing is, I want to design and write code. I don't want to remember a bunch of command line parameters for other stuff.

With Mercurial I didn't have to, it just flowed.

I know the operation I want to perform. I even know approximately what it's called. I can't be bothered to remember what obtuse syntax is required to invoke it.

Rebasing isn't difficult, merging isn't difficult. Staging is stupid so I ignore it. The stash is stupid, so I ignore it (why not just make a new branch and commit?). Bisecting isn't difficult.

Seriously, the concepts are not rocket science. Git just makes it hard to remember how to correctly invoke the thing you want to do for no good reason other than that it was hacked together in a fit of pique and those decisions have stayed with us ever since.

And a lot of the functionality is centered around an email-based workflow, which makes sense for the Linux kernel, and doesn't make sense for anybody else.

While I agree that Mercurial has done a better job with the cli and docs for making things simple, you've linked to the reference of git-reset instead of the equivalent doc for undoing things [1] which is much simpler and covers similar cases. One thing I note is that in the doc you linked switches that are default behaviour are typed out. If I look at my shell history the git commands I'm actually typing look closer to the Mercurial doc than the git doc.

[1]: https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things

Reply on news.ycombinator.com