Keep TODOs in git(coderwall.com)
coderwall.com
Keep TODOs in git
https://coderwall.com/p/r2g2rq
26 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.
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.
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!
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.
Why not just use 'git notes'? This seems like exactly the sort of use case that feature is for.
Would notes survive a rebase workflow? (not that the original tip's empty commit does, which is quite a flaw)
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.
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.
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.
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.
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.
Git (and dvcs generally) is a nice hammer to hit all sorts of things that look like storage/content/versioning nails.
Interesting. I was looking for a demo but bugs.bugseverywhere.org is currently down.
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.
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.
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
https://github.com/schacon/ticgit
The last commit is two years old and points to: https://github.com/jeffWelling/ticgit
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)
(per https://github.com/schacon/ticgit#readme)
Wow, nice tip. Seems like combining this with Sublime Todo (https://github.com/robcowie/SublimeTODO) would make for a really good setup.
The best TODO tool for me is pen & a paper. Silence is also the best music I have found to listen to while working :)
Anyone using http://todotxt.com/?
I pretty much always have a file called TODO in version control.
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.
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.
Bad advice. Keep tasks in issue tracker.
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: