I have to say I was hoping to see a little more magic in there. I've only been using Git for two weeks, feel like I still don't have my head completely around it, and the only thing covered I didn't know about was "stash".
Here's some magic, then. Say you've got a bunch of commits that you haven't pushed yet, and you don't like the way you did them. You worked on one thing for a while, fixed something else, worked on another thing, went back to the first thing: it's a mess.
"git rebase --interactive HEAD~10" will bring up a $EDITOR window with the last 10 commits listed. You can rearrange them, squash them into each other, delete some entirely. Save the file, and git will happily rewrite history for you.
Just keep in mind that it hardcodes the operation to the last ten generations of commits, which is not necessarily what you want. See "SPECIFYING REVISIONS" in the man page for git-rev-parse (http://www.kernel.org/pub/software/scm/git/docs/v1.6.1/git-r...) for all the different ways you can format the HEAD~10 part.
Then again, I have an alias "git cia" for "commit -a"... Just remember where to look it up if you need something more elaborate.
Ideally what you want is a "useful" history, not an actual one. And by "useful" I mean one where the changes in each commit are related to a specific, self-contained update (feature addition, bug fix, etc.).
That way you can branch at any point in the commit history and be sure it'll run cleanly or cherry-pick a change without having to remember everything that it might depend on. And you get exactly what you want and nothing more.
Because some people like to commit a lot...I once had a project where I committed after every red/green cycle. If specs were green and there was uncommitted code, I committed.
That's only useful for me, during tight development loops, not to a historian looking back at what I actually did. So before I push to others, I squash it to a changeset, possibly keeping all the commit messages in the single commit.
Comments
I have to say I was hoping to see a little more magic in there. I've only been using Git for two weeks, feel like I still don't have my head completely around it, and the only thing covered I didn't know about was "stash".
Here's some magic, then. Say you've got a bunch of commits that you haven't pushed yet, and you don't like the way you did them. You worked on one thing for a while, fixed something else, worked on another thing, went back to the first thing: it's a mess.
"git rebase --interactive HEAD~10" will bring up a $EDITOR window with the last 10 commits listed. You can rearrange them, squash them into each other, delete some entirely. Save the file, and git will happily rewrite history for you.
See this blog post for a little more detail: http://blog.madism.org/index.php/2007/09/09/138-git-awsome-n...
If someone else is lazy like me, you can put the following in your ~/.gitconfig
Then you can just use 'git magic' instead of writing the full command.Just keep in mind that it hardcodes the operation to the last ten generations of commits, which is not necessarily what you want. See "SPECIFYING REVISIONS" in the man page for git-rev-parse (http://www.kernel.org/pub/software/scm/git/docs/v1.6.1/git-r...) for all the different ways you can format the HEAD~10 part.
Then again, I have an alias "git cia" for "commit -a"... Just remember where to look it up if you need something more elaborate.
Be careful not to rewrite history you have already pushed.
I always use
That only shows me commits that are local.What is the big deal about keeping a clean history?
It's always seemed so much effort than it's worth.
Besides, isn't it better to keep a history of what actually happened? Something about being doomed to repeat it comes to mind...
Ideally what you want is a "useful" history, not an actual one. And by "useful" I mean one where the changes in each commit are related to a specific, self-contained update (feature addition, bug fix, etc.).
That way you can branch at any point in the commit history and be sure it'll run cleanly or cherry-pick a change without having to remember everything that it might depend on. And you get exactly what you want and nothing more.
Because some people like to commit a lot...I once had a project where I committed after every red/green cycle. If specs were green and there was uncommitted code, I committed.
That's only useful for me, during tight development loops, not to a historian looking back at what I actually did. So before I push to others, I squash it to a changeset, possibly keeping all the commit messages in the single commit.
Dude, that's awesome. You made my day.