[merlincorey]

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.

[evincarofautumn]

Right. I prefer GitHub issues nowadays, but a TODO file is totally reasonable.

[jaggederest]

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.

[travisb]

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.

[binarymax]

I do this with tdl and add the .tdldb file to my commits. Works great!

[dpcx]

Funny that neither Google nor Bing know what "tdl" is on the first page of results; luckily, tdldb makes it work.

[voltagex_]

I've done it with a markdown file before - what are the advantages of tdl? (Never heard of it until now)

[christiangenco]

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.