Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

241–250 of 520 posts

Re: Oh shit, git: Getting myself out of bad situations

#241

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

Additionally you can always use the command line if you need to. I use a GUI for 99% of what I do, then use the CLI for what I need it for.

Re: Oh shit, git: Getting myself out of bad situations

#242
post #219

Earlier quoted context omitted.

Well. That depends :) I don't develop in Emacs and use it solely for hosting Magit, in a separate window. So it's kind of a GUI I guess; more so than a CLI anyway. > It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.) Don't remember a single of case of it feeling too slow in the last few years, whether on linux/mac... (maybe it just got better over time though…

interesting. i'm on mac; i'll have to give it another try. also we might just have different ideas of "too slow"; for common operations, anything more than instant is basically too slow. :-)

On macOS it helps to use Emacs 26.1 (unreleased but very solid) or to use a build with a backport of the vfork patch. For more information see https://magit.vc/manual/magit/MacOS-Performance.html.

I also plan to make Magit faster across all platforms.

Re: Oh shit, git: Getting myself out of bad situations

#243

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.

I'd like to also point out tig. "Tig is an ncurses-based text-mode interface for git"

It doesn't have all the bells and whistles of a GUI, but if you need to look at all the branches, and commits to a repository. tig is an excellent tool. tig doesn't issue any commands though, its only a browser, you'll still need to know the CLI. (essentially a ncurses version of gitk)

I'm normally in a ssh session on a remote box where my compile & run cycles happen. tig is curses based, so no X11 needed, filled in a really nice itch of mine.

[1] https://github.com/jonas/tig

Re: Oh shit, git: Getting myself out of bad situations

#244

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Or, you know, understands and thinks in the semantics of the underlying tool and is already working in other text-based tools.

Doesn't really make the interface any less crap; though I've yet to see a GUI that didn't shell out to the command-line interface (which almost always makes them very unreliable).

Re: Oh shit, git: Getting myself out of bad situations

#245

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.

For any Windows users out there, I use GitExtensions, which has served me very well over the years.

Re: Oh shit, git: Getting myself out of bad situations

#246

Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…

> I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI.

Nah, it’s just a lot easier than you make it out to be. GUIs are fine too, but if you read the documentation and don’t just memorize a fixed set of commands there’s nothing dangerous, slow, or inconvenient in going about a standard workflow using the CLI.

And yes, lots of people don’t have time for this. Totally okay. Don’t generalize to “anyone who uses the CLI is trying too hard”.

Re: Oh shit, git: Getting myself out of bad situations

#247
post #187
post #123

Earlier quoted context omitted.

I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz. When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do…

It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embracing git's model. The one exception to this I've found is GitUp (mac only, sadly), and it's excellent. It's whole model is, "what operations can I perform on this graph," which is exactly the model git has. It's great.

I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, git's underlying model is so simple and powerful that I think it's worth suffering the bad CLI just to be more fluent and able to utilize git's power fully. The model itself is very easy to grok, it just takes some time to memorize the various random incantations and occasionally look something up, but I don't consider that a big deal for a core tool I use every day.

Re: Oh shit, git: Getting myself out of bad situations

#248

In three years of using git I believe there is a single bad command that I could not undo: `git checkout -- somefile` The second worst thing I did is losing a commit in a `git rebase -i` but I was able to find it back with `git reflog`. Which makes me think that git is really well designed.

I recently had one of those holy-crap-what-did-I-just-do-I-lost-everything moments... But then realized that my scrollback had a list of files and my IDEs (PhpStorm and WebStorm) both kept _local_ revision histories and I was able to restore everything I had done.

This combined with Time Machine backups means I haven't lost source in years.

Re: Oh shit, git: Getting myself out of bad situations

#249
post #219

Earlier quoted context omitted.

interesting. i'm on mac; i'll have to give it another try. also we might just have different ideas of "too slow"; for common operations, anything more than instant is basically too slow. :-)

On macOS it helps to use Emacs 26.1 (unreleased but very solid) or to use a build with a backport of the vfork patch. For more information see https://magit.vc/manual/magit/MacOS-Performance.html . I also plan to make Magit faster across all platforms.

very cool to hear that performance is a focus area!
Post reply on HN