News for hackers. Stuff that matters.
Re:Oh shit, git: Getting myself out of bad situations by xaphod on Monday December 18, 2017 @03:52PM (#15955396)
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.

Re:Oh shit, git: Getting myself out of bad situations by bpchaps on Monday December 18, 2017 @04:10PM (#15955537)
Sure it's wrong if you know what you're doing. But that's not who the blog post is for.

Sometimes it's okay to take liberties with good practices - especially when learning, or when the world is on fire and a push needs to happen now.

Re:Oh shit, git: Getting myself out of bad situations by richforrester on Monday December 18, 2017 @05:22PM (#15956051)
> or when the world is on fire and a push needs to happen now.

The unwanted reality we live in.

Re:Oh shit, git: Getting myself out of bad situations by jsmthrowaway on Monday December 18, 2017 @04:06PM (#15955508)
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 choice to spend the next hour typing the right Git commands to get back where you wanted to be, or just back out and try again. I know which one I'd prefer.
Re:Oh shit, git: Getting myself out of bad situations by xaphod on Monday December 18, 2017 @05:43PM (#15956169)
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 <commit>)

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 by jsmthrowaway on Monday December 18, 2017 @05:58PM (#15956260)
> git reset --hard <commit>

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 by u801e on Monday December 18, 2017 @07:56PM (#15956917)
You could run git reset without the --hard parameter to keep unstaged changes in the working directory
Re:Oh shit, git: Getting myself out of bad situations by minor3rd on Monday December 18, 2017 @06:27PM (#15956402)
It's only easier to copy the directory if you haven't done the due diligence of learning git properly. It's a tool to avoid doing the ripcord approach -- ever.
Re:Oh shit, git: Getting myself out of bad situations by iamjaredwalters on Monday December 18, 2017 @08:58PM (#15957167)
Why not just create a new branch instead of copying your project over to a new dir?