Keep TODOs in git

evincarofautumn 13 years 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
    }

merlincorey 13 years ago | |

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 13 years ago | | |

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

jaggederest 13 years ago | | |

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 13 years ago | | |

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 13 years ago | | |

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

dpcx 13 years ago | | |

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

voltagex_ 13 years ago | | |

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

christiangenco 13 years ago | | |

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.

eeperson 13 years ago |

Why not just use 'git notes'? This seems like exactly the sort of use case that feature is for.

Tobu 13 years ago | |

Would notes survive a rebase workflow? (not that the original tip's empty commit does, which is quite a flaw)

eeperson 13 years ago | | |

It appears that the notes survive a rebase but they don't point to anything in your history. They continue to point to a commit before the rebase.

Tobu 13 years ago | | |

Too bad. As I understand it that's because rebase relies on the patch format as the full representation of a commit; but that excludes the commit's notes. replacement refs and grafts survive it in squashed form because they are part of the graph traversal.

kamaal 13 years ago |

Nice,

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.

emmelaich 13 years ago |

For a more fancy mature solution, consider http://bugseverywhere.org/

Git (and dvcs generally) is a nice hammer to hit all sorts of things that look like storage/content/versioning nails.

alexabramov 13 years ago | |

Interesting. I was looking for a demo but bugs.bugseverywhere.org is currently down.

ultimoo 13 years ago |

clever code: keeping an empty todo commit in the repo tree.

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.

emillon 13 years ago |

For that purpose I use ticgit which creates an unrelated branch in a git repository to store data. There's even a web client if you want to go fancy.

https://github.com/schacon/ticgit

Tobu 13 years ago | |

The last commit is two years old and points to: https://github.com/jeffWelling/ticgit

mh- 13 years ago | |

just a heads-up in case others overlook the note in the readme, the canonical repo is now at https://github.com/jeffWelling/ticgit

(per https://github.com/schacon/ticgit#readme)

micahmcfarland 13 years ago |

Wow, nice tip. Seems like combining this with Sublime Todo (https://github.com/robcowie/SublimeTODO) would make for a really good setup.

baghali 13 years ago |

The best TODO tool for me is pen & a paper. Silence is also the best music I have found to listen to while working :)

ricardobeat 13 years ago |

Anyone using http://todotxt.com/?

general_failure 13 years ago |

I pretty much always have a file called TODO in version control.

j-m-o 13 years ago | |

Agreed, at least for independent projects.

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.

EugeneOZ 13 years ago |

Bad advice. Keep tasks in issue tracker.