You can test exactly what you're about to commit by doing a `git stash save --keep-index`, then test, commit, and `git stash pop` to get your working tree back.
I learned it because of the general -i; the -p was the only portion of -i that I really use with "git add". The -i is what makes "git rebase" more than just a patch pusher.
Isn't this what branches are for? This seems ridiculous.
I applaud the ingenuity but I think the author would be better off making a shortcut/alias to create a branch from the current head with some interesting name and commit message and commit the changes to the new branch, then switch back to the current one.
One accidental "git stash clear" and this dude's setup is wiped!
Interesting idea, I played with branches and added a simple script to the end of my blog post to show what it would take - it's a half dozen lines of git if you want so skip the click, with the tricky bit being figuring out what branch you start from so you can return to it.
Seems workable, though by the time you're done working out the details, seems like you should just use a real issue tracker.
I think of my approach as the moral equivalent of post-it notes on the monitor, I wouldn't want to base any important system on it, but it's useful at times.
I believe you're describing creating a branch with one commit that only contains a selection of the changes in the index. What are the commands to do that?
Ah I think I missed that nugget when I read the article... he is committing just a partial with his one TODO diff only. I didn't notice that.
Still he should use an issue tracker, and then some branches :)
In fact a guy at our company hacked out a really cool git-pivotal integration that lets you create a branch to work on a specific story from the CLI https://github.com/ardell/Git-Pivotal I think it'd be trivial to write a simple CLI script to add a TODO to an issue tracker this way as well.
