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

411–420 of 520 posts

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

#411

Post by xaphod »

jsmthrowaway wrote: post #369
xaphod wrote: post #364

Earlier quoted context omitted.

This is so wrong. :) With git you exactly do not have to backup your local workspace, because it already is backed up in git. If it is committed, it is safe. You can go back to it. If you messed up your branch, just reset it to something that was good. No need to do manual backups.

No, it isn't, if you're playing with surgical tools that disrupt Git history, which was my point. It's a lot easier to revert to before you started than attempt to abort out of a huge rebase/squash/ugly merge conflict hell/rewrite of history. I'm not saying back up before every commit. I'm saying when `git status` is three pages long, you have 14,000 conflicts, and you're on a detached HEAD God knows where, it's your…

I'm sorry if I sound rude. I don't mean to be. I'm just saying that backing up your git workspace to recover from rebases or merges gone wrong is not necessary. Those are not "surgical tools", they don't modify existing commits. (edit: yes you can "edit commits", but they only create new commits, the old commits are not deleted in the process and they can still be found easily)

When you commit in git, that saves the whole project as a "snapshot". If you find yourself lost in some rebase hell or whatever, just reset HEAD back to a previous commit. It's simple as that! (git reset --hard )

Why I decided to reply to your comment was because this is a very crucial part of learning git. When you realize that you can always go back to what was before, you can start experimenting more freely.

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

#412

Post by lkrubner »

dennisgorelik wrote: post #310
lkrubner wrote: post #258

Earlier quoted context omitted.

* Your attitude is the exact opposite. * You setting your theory against my lived experience. If you want to understand the situation more fully, you can read How To Destroy A Tech Startup In Three Easy Steps: https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09... I did my best to re-create the extent to which decisions were driven by panic and the pressure of time. Please note, every company in the world ha…

> Sital's attitude was a major problem Would it be the best if Sital never committed his changes? That way he would not be able to hurt your project and you would be able to fire Sital sooner.

My leadership philosophy is "fire fast". I shouldn't have to jump through a bunch of hoops to fire someone, at least not under the rules that hold sway in the USA. Obviously the approach needs to be adjusted to fit with the laws of whatever nation you might be in. But in the USA, the law is lenient towards leadership when leadership wants to fire someone. Therefore, I should have been able to simply fire Sital. Then we would have hired someone good.

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

#413

Post by mikedelfino »

dasil003 wrote: post #247
dilap wrote: post #187

Earlier quoted context omitted.

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…

One could also setup aliases for some of the incantations. I personally have `git uncommit` aliased to the proper command line that I never remember.

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

#414

Post by electricEmu »

WhyNotHugo wrote: post #377
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…

Same here. Regrettably, if you UNDERSTAND git, a GUI won't work for you. If you're interested in understanding it, it won't work for you either. A GUI works fine if you want to get things done. If you like to know what goes on under the hood, it's just confuse you.

I understand git quite well and use a GUI. I was interested in understanding it while using the git.

It's pretty sweet that GitExtensions displays the exact command executed. Actually, it made learning vastly easier for the people I taught after myself.

Some people do better with GUIs; others the CLI.

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

#415

Post by mikedelfino »

thelittleone wrote: post #404
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…

How about if someone made a GUI with a console at the bottom that showed the commands being executed along with results?

I like typing and I don't think it slows me down too much, so I pass. But it's a good idea.

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

#416

Post by jsmthrowaway »

xaphod wrote: post #411
jsmthrowaway wrote: post #369

Earlier quoted context omitted.

No, it isn't, if you're playing with surgical tools that disrupt Git history, which was my point. It's a lot easier to revert to before you started than attempt to abort out of a huge rebase/squash/ugly merge conflict hell/rewrite of history. I'm not saying back up before every commit. I'm saying when `git status` is three pages long, you have 14,000 conflicts, and you're on a detached HEAD God knows where, it's your…

I'm sorry if I sound rude. I don't mean to be. I'm just saying that backing up your git workspace to recover from rebases or merges gone wrong is not necessary. Those are not "surgical tools", they don't modify existing commits. (edit: yes you can "edit commits", but they only create new commits, the old commits are not deleted in the process and they can still be found easily) When you commit in git, that saves the…

> git reset --hard

Unless part of your surgery involves files that do not yet live in the history, or you're working on a detached HEAD in a mid-merge state, or... git reset --hard is a very dangerous operation unless you're 100% sure of the entire state of the repository. That is a very rapid way to lose work if you're not perfectly diligent.

And sure, you shouldn't have to back up .git or your workspace, but sometimes, it's a hell of a lot easier to ripcord out and say "screw it" if you have a complete workspace from before you decided to launch down the rebase hole or whatever.

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

#417

Post by inferiorhuman »

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…

Once upon a time I found a git GUI that I liked (SourceTree). Then Atlassian bought it and pushed their cloud nonsense on me so hard that I just gave up and reverted back to the command line. Eventually I bought the O'Reilly book and figured out how to do the neat things that SourceTree would let me do. Only this time the GUI wouldn't get borked while trying to stage individual lines.

I haven't looked back because I haven't found the need.

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

#418

Post by dasil003 »

chiefalchemist wrote: post #401
dasil003 wrote: post #247

Earlier quoted context omitted.

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…

It might not feelblike that big of a deal, but certainly there has got to be on any given day far more important things you can use those brain cycles for, yes? Low friction or not it's still friction. Friction that can be removed. Yet so many refuse to do so. There's something wrong with this this-is-how-we've-always-do-it picture.

You make it sound like tradition or a cargo cult—it's not. Git is fundamentally better than most of the alternatives, but in my opinion it's misguided to try to slap a better interface over the warts. Rewriting the porcelain would be good, but I don't think it's personally worth investing in until someone makes an attempt that's good enough to get traction and significant mindshare. In the meantime I've already made the investment in learning git and it pretty much stays out of my way.

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

#419

Post by dasil003 »

DigitalJack wrote: post #348
DigitalJack wrote: post #340

Earlier quoted context omitted.

> Fugitive That's interesting. I switched back from emacs to vim (neovim), and fugitive was recommended. it just looked like :commands for the normal git cli... maybe I missed something. So even though I edit in vim, I jump back to emacs for magit for bigger commits or multiple smaller commits (where I need to see diffs to be sure I capture my changes). I have desired something as useful in vim, but I didn't think th…

Yeah, fugitive seems pointless to me. Might as well just use the git cli...which I do, but when I want something quicker to navigate/visualize, magit is my go to.

See my comment in sibling thread. I am not familiar with Magit, but there's no equivalent on the CLI to Fugitive's flow for rapidly traversing history, it's really really useful, and lets me answer questions that other devs on the team just throw up their hands because a line may have traversed several different files over dozens of commits throughout its history. The reason it can't be done on the CLI is because you need multiple buffers and window management to make it viable.

All that said, I don't really use it for committing, mostly because I have a shell open right next to the editor anyway.

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

#420

Post by gknoy »

tigershark wrote: post #327
deragent wrote: post #218

Earlier quoted context omitted.

Within 'git add -p' when you get to the hunk that you want to edit (split down to single lines), press 'e'. This will open an editor (vim in my case) which lets you edit the diff manually. In there you can remove added lines (prefixed by '+') by removing them, and re-adding removed lines (prefixed by '-') by replacing the '-' with a space ' '.

And how is this faster/better than selecting a line with the mouse and pressing s without opening any other editor?

Sometimes your changes are across multiple files, and it's easier to say, "yes, yes, yes, yes, split, no, no, yes, ..."
Post reply on HN