41–50 of 352 posts
# create a new branch from the current state of master
git checkout -b some-new-branch-name
# remove the commit from the master branch
git checkout master
cd ..
sudo rmdir nsfw-git-repo-dir
Still, amusing :)
Next on the list: Larry McVoy's Bitkeeper promises to be everything git and Mercurial aren't. (git is "inspired" (read: copycat) by Bitkeeper).
It's funny how Sun Microsystems influenced the industry in so many ways, isn't it?
Actually 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.
You need to expand on this because i don't quite understand what you mean, are you talking about "fix typo" commits or are we getting to the level of just committing away until things work and then not cleaning up the work later on? The linked article doesn't cover rebasing or squashing commits, which can be pretty powerful when used correctly.
Your commit log is the one thing that is immutably linked to your code changes. Your documentation isn't, the comments in your code aren't, you will forget why you made a change, anyone reviewing your logs needs to understand your intention, your bug tracker will probably change several times over the life of a project, and so on. So, make an effort to have a commit log that is clean and comprehensive and commits that don't break tests.
I go into this in more detail in a talk i gave last week: https://www.youtube.com/watch?v=9OHAq8dCoS4
I 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…
Actually 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…
Yep. Some people just want to keep taking technical debt on (read: hack-it-'till-it-works), which makes them likely candidates for a good thrashing in some dark blind street in the middle of the night. And some don't even get it after that. Actually, now that you made me think about it, most people in this industry aren't really computer people material, that's the problem.
alias gitshit="open http://ohshitgit.com/"
I 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…
It's better to accept history as it is, and fix the problem with reverts, cherry-picking and new commits. History won't be as pretty or clean, but it will reflect what actually happened, which is what history is, after all.
The biggest trick to understanding git is to learn to think in commits rather than file content. If one branch has a commit and the other branch doesn't, merging them will mean that the commit is there. If one branch has the commit while the other branch has the commit and a revert for that commit, merging will mean it will be reverted.
Same goes with pushing. If you reset locally to before a commit that you already shared, that commit returns on your next pull. If you revert it, it will stay reverted.
The most dangerous thing git can do, is rebasing. Rebase changes history. This is fine if it hasn't been shared yet (you commited a new change and try to push, but remote changes need to be pulled first, so rebasing is fine). Rebasing is not fine if the commit has already been shared, through a different branch or a different remote repository, for example. In that case, you need a merge.
As pretty as rebase can make your history, you should really only use it when you understand what it does. If you don't, stick with merge.
Earlier quoted context omitted.
For posterity, `rmdir` will only remove empty directories. The author presumably should have used `rm -rf`.
I think the command we're looking for is 'rm -R name_of_directory'