Hacker News new | ask | show | jobs
by evincarofautumn 4814 days ago
This is a bad idea. I can come up with a TODO at any time; I especially do when I’m in the middle of something and have staged local changes. In that case, this:

    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
    }
1 comments

Before reading the article, I thought it was going to be about keeping a TODO file in your revision control so that you can see when things are added/removed by reviewing the history.
Right. I prefer GitHub issues nowadays, but a TODO file is totally reasonable.
I think it's particularly nice because you can see which tasks exist on which branch, in an ideal world, at least.

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.

That is one advantage of on-branch distributed bug tracking. One advantage you also get, which is more important on large projects, is knowing which bugs have had their fixes merged into the branch you are working on. This is a bit unwieldy with just text TODO files since you have to keep finished TODOs around and then merge them, usually manually solving conflicts, as changes move between branches. For this purpose I use a dedicated distributed bug tracker https://github.com/travisb-ca/nitpick after I had evaluated pretty much all the alternatives.

For a very small team a simple text file can work, but for teams of more than a handful some tool support is necessary.

I do this with tdl and add the .tdldb file to my commits. Works great!
Funny that neither Google nor Bing know what "tdl" is on the first page of results; luckily, tdldb makes it work.
I've done it with a markdown file before - what are the advantages of tdl? (Never heard of it until now)
Ditto. I have a todo.md in almost all of my git repositories. Once I finish a feature, I delete the line from the todo file and throw it in the same commit.