Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oh shit, git: Getting myself out of bad situations

ohshitgit.com

Post reply on HN
Print view View original

191–200 of 520 posts

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

#191

Post by aldanor »

gumby wrote: post #137
emeraldd wrote: post #59

Earlier quoted context omitted.

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.

> What GUI do you recommend? I really like Magit, which is a git GUI you can use without leaving Emacs. It handles 90% of my git needs and is very tightly integrated into my IDE (Emacs). I still use some shell commands (like git mv) occasionally but those are simply m-! away.

Second that; I'm using Spacemacs just for Magit and nothing else, although it's mainly vim or clion for development. Haven't seen a single git client that would be close to Magit; too sad it needs Emacs, could have potentially been an awesome standalone...

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

#192

Post by dilap »

aldanor wrote: post #186
swalsh wrote: 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…

There are GUIs that are very close to CLI that don't try to reinvent a wheel and instead just map directly to what git does. The best one, I think, being Magit for Emacs (if you can call that a 'GUI' given you can run it in the terminal). If you get used to commit things by-line instead of by-file (which is generally highly recommended with git), and also clean up your history/squash things a lot, using git cli gets…

Sort of off-topic, but magit isn't really GUI :-) -- though it is very nice, if you're an emacs user. It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)

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

#193

Post by dilap »

STRiDEX wrote: post #168
swalsh wrote: 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…

I use sourcetree, but I would like a console feature that shows me what commands its running. Similar to sequel pro's "console" feature shows the raw sql being run.

the commands themselves are not actually the lowest level, though! (and in fact, are kind of crazily mixed togther; most of the trouble people have w/ git is bad UX for the cli, imo.)

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

#194

Post by m6PeelVLsQ8QawN »

lmm wrote: post #62
m6PeelVLsQ8QawN wrote: post #2

It happens to everyone :) I'd like to contribute my list of git booboos: https://github.com/1337/yesterday-i-learned/blob/master/git....

> I used git in the terminal and the diffs/patches/merges/pull requests don't turn out right Your answer there is just doing git pull --rebase by hand. I don't like that style at all, but if you must do it surely use the command that's designed for doing it. > I pushed stupid things onto the remote server Worth saying you can branch before fixing - that might be a little less intimidating than "access by commit ID" >…

Thanks for the review! I actually wrote that years ago (in frustration). Will give it a revision when I have time.

I think I would rebase my PR comment history away only if "the repo owner wants me to rebase it to a single commit". In that case, I'm just doing whatever the repo wants the repo to be structured.

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

#195

Post by aldanor »

dilap wrote: post #192
aldanor wrote: post #186

Earlier quoted context omitted.

There are GUIs that are very close to CLI that don't try to reinvent a wheel and instead just map directly to what git does. The best one, I think, being Magit for Emacs (if you can call that a 'GUI' given you can run it in the terminal). If you get used to commit things by-line instead of by-file (which is generally highly recommended with git), and also clean up your history/squash things a lot, using git cli gets…

Sort of off-topic, but magit isn't really GUI :-) -- though it is very nice, if you're an emacs user. It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)

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)

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

#196

Post by trevor-e »

I think Git would be way more approachable if things were named better. A key part of Git is whether a file is untracked/unstaged/staged, yet the terminology around this is very confusing. Why aren't commands simply `git stage`, `git unstage`, `git add` (to track files), `git remove` (to untrack), `git undo`, etc? Not to mention the overloaded command names like `git checkout`, how is `git checkout -- someFile` intuitive at all?

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

#197

Post by theptip »

reificator wrote: post #164
dasil003 wrote: post #151

Earlier quoted context omitted.

You're entitled to your own opinion of course, but you underestimate the efficiency of the command line, especially when you already have one open for other development tasks. I use one or more GUIs for visualizing branches, and old branch cleanup, and yes, committing single lines from hunks that can't be split. However for everything else CLI is fairly close to optimal, including interactive adding/rebasing, and don…

> committing single lines from hunks that can't be split. Could you elaborate here? Personally I've always been able to commit just the pieces I need via `git add -p`. Never had problems staging a single line before. Since this is text I should say: I'm not doubting you, I just like to know the limitations of the tools I'm using.

`git add -p` adds by the hunk, which is a unit of quantization bigger than a line.

E.g. if you have two consecutive lines changed, it's not possible to split them, they are one "hunk".

(Waiting for someone to chime in with how to split a hunk and change my life).

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

#198

Post by JetSetWilly »

dilap wrote: post #192
aldanor wrote: post #186

Earlier quoted context omitted.

There are GUIs that are very close to CLI that don't try to reinvent a wheel and instead just map directly to what git does. The best one, I think, being Magit for Emacs (if you can call that a 'GUI' given you can run it in the terminal). If you get used to commit things by-line instead of by-file (which is generally highly recommended with git), and also clean up your history/squash things a lot, using git cli gets…

Sort of off-topic, but magit isn't really GUI :-) -- though it is very nice, if you're an emacs user. It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)

It seems to be incredibly slow on windows, but fine on linux.

It seems like the sort of ui that needs to be near-instant in order to be usable, the premise being you can tap the various shortcuts to assemble a command very rapidly. But on windows this is an exercise in frustration because each command takes at least a second or two at best to execute and often much longer.

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

#199

Post by lemoncucumber »

oelmekki wrote: post #73

Maybe it's not worth being in there because of how simple it is, but I guess it would be useful for newcomers: # Oh shit, I've changed 200 files and want to revert to the state of this morning $ git add . && git commit # often. Very often. $ git reset --hard commit_id

I think this is bad advice for git newbies two reasons:

1. ‘git add .’ is dangerous and should be avoided IMO, in case you ever have files around that you don’t want to commit. I frequently do. It’s better to ‘git commit -a’, and to just remember to run ‘git status’ frequently and ‘git add’ any new files.

2. ‘git reset —-hard’ is dangerous as well for newbies, since it’s destructive. Better to ‘git revert’ or to ‘git checkout ; git checkout -b ’, such that you can always get back to where you were.

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

#200

Post by flatline »

emeraldd wrote: post #59
lwansbrough wrote: post #42

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 personally switch between the command line, git gui and gitk. I haven’t yet found a suitable GUI replacement for those two.
Post reply on HN