git commit --allow-empty -m "TODO: $*"
Will do the wrong thing—committing my staged changes even if I didn’t want that, and giving them a wrong commit message. If the change is small, I might not notice. If I were going to involve Git in my task tracking, I would much prefer something like this: todo() {
touch TODO
printf "%s\n%s\n\n" "$(date)" "$*" | cat - TODO > TODO.tmp
mv TODO.tmp TODO
$(git config core.editor) TODO
}It doesn't make sense to me to have a global bug repository that may or may not be present on any given branch or checkout of your repository.
But I've checked nearly everything thing out. Online kanban boards, Trello, Asana, Org-Mode you name it...
Its extremely hard to beat the flexibility of a diary and pencil/pen. You can doodle, scratch, draw, record, take notes, maintain time, review history, write a lesson, work out problems... The list is endless... You can do all this in a easy extremely distraction less tool. And to be frank maintaining a diary gives me a great deal of discipline in fighting procrastination. Diaries also are great progress indicators.
Most successful people I know maintain diaries. Diaries and Pens are here to stay.
Git (and dvcs generally) is a nice hammer to hit all sorts of things that look like storage/content/versioning nails.
clear code: keeping a textual todo or org mode file committed in the repo.
While this is another fun and a clever trick that can be done with git and it delights the geek within me, I wouldn't do this while collaborating on production code with a team.
I could use all sorts of git tricks that could do the same thing, but sometimes it's nice to just keep an easy, version controlled text file I can knock things off of.
That said, I frequently sprinkle in '//TODO: ...' or '//XXX:' in source code comments when I'm in the middle of hacking. It's pretty easy to aggregate those back into my main todo list when I'm done.