'sudo rmdir'? I don't think that does what they think it does.
For posterity, `rmdir` will only remove empty directories. The author presumably should have used `rm -rf`.
Some bad Git situations and how I got myself out of them
31–40 of 352 posts
Re: Some bad Git situations and how I got myself out of them
#32> Oh shit, I accidentally committed to the wrong branch! Other ways to do it (that don't require to retype the commit message): - rebase onto the correct branch: git branch foo git reset --hard HEAD~ git rebase --onto name-of-the-correct-branch HEAD foo git checkout name-of-the-correct-branch git merge foo git branch -D foo - cherry-pick git reset --hard HEAD~ git checkout name-of-the-correct-branch git cherry-pick n…
Or use git branch -m to rename master to something else, then checkout master anew.
Or this variant
git checkout -b actual-branch
git branch -f master origin/masterRe: Some bad Git situations and how I got myself out of them
#33Earlier quoted context omitted.
It was also a bit pointless to checkout a new branch just to switch back. The whole thing should be git branch some-new-branch-name git reset --hard origin/master git checkout some-new-branch-name
The "committed to wrong branch" case is also a little overly complex. I'd just do: git checkout correct-branch git cherry-pick wrong-branch git checkout wrong-branch git reset --hard HEAD~
This is less safe than the branching alternatives. Instead of "moving" the original commit, this copies the original commit to a new one and leaves the original one dangling and waiting to be garbage collected.
Also, if you have more than one commit before you noticed you were on the wrong branch, this only grabs the one commit.
Re: Some bad Git situations and how I got myself out of them
#34I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic, I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools.
I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs provide. If you've made some unrecoverable mistake with an important set of changes, you can always review the history in the same GUI and reimplement the important changes in a new branch.
Re: Some bad Git situations and how I got myself out of them
#35Re: Some bad Git situations and how I got myself out of them
#36Actually the easiest thing is simply not to care about how your log looks. If you don't then there are ry only two things you need to know how to do: If you didn't push to origin do an ammend. If you did, revert soft and commit the previous code to revert it (you can also put a stash or patch to apply it back). Which frankly is what the article does, basically.
> Actually the easiest thing is simply not to care about how your log looks.
Yes, that sounds as easy as anything that accepts the idea of "let's do this the shitty-but-quick way now, and pay the technical debt later". So yes, it is "easier" to work with in the beginning.
On the other hand, if I had to inherit your repository that was developed by "not caring about history", I would probably have to hunt you down and kill you. So there's that.
Re: Some bad Git situations and how I got myself out of them
#37I moved to git at the begining of this year and I must say that I miss SVN. But everyone keeps telling me that git is better so I'm sticking to it.
Re: Some bad Git situations and how I got myself out of them
#38I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than m…
I think there's a bit of that in git in particular. The irony is that if you think of git in terms of deltas, with branches just being tags to commits, and "git commit" actually being "git commit + move branch", then a lot of stuff is easier to reason about. Like, if you get the notion of working tree, staging area, commits, and branches on a deep-ish level, things get easier. Things can still be hard, but there's a…
> and "git commit" actually being "git commit + move branch"
Can you elaborate on that a little more? I liked where it was going -- because being able to explain how git works to someone coming from SVN has been an ongoing problem for me.
Re: Some bad Git situations and how I got myself out of them
#39Is the documentation really that bad? Would it benefit from a technical writer going over it? Is the project open for discussion on changes to the documentation?
Re: Some bad Git situations and how I got myself out of them
#40[deleted]