My 2 cents:

I don't like much the idea of naming a branch by a number. I use git-flow (https://github.com/nvie/gitflow) and there is a standard name convention.

It would be nice to adapt the pit hook to branch name of the form : pit<num> or in regexp /.pit\d+$/

On the other hand I use wedoist.com They don't have any API for now (http://wedoist.com/Help/showQuestion/137) It would definitively be great to have the ability to synchronize task with this service.

I have been looking at ditz recently. I fail to see the point of using C for something like this though?

That's where the "from hell" part comes in.

From the readme

> I wrote it because I needed a command-line tool for tracking tasks. Besides, after years of Ruby and JavaScript programming I missed plain C.

If he needed a command-line tool for tracking tasks, why couldn't he use ditz?

Other than the fact that they're both command-line project managers, these don't look all that similar. Among other things, pit is designed to store your data in your home directory, while ditz is designed to store it in your VC system. Pit has git commit hooks, but it doesn't look like ditz does.

Bloat. Pit is ~50K executable with no dependencies storing all the data including activity log in single .pit file.

oh, this is good.

_Nothing_ beats command line productivity. If it all happens at the same moment I'm managing git, I expect this tool to be perfect for project management needs.

Spot on.

This could be really interesting project, however using locally stored tasks for a project hosted in distributed VCS renders it pretty much useless.

Come on Piotr, it's the very first version, how can it be useless? :-) BTW you can store .pit file anywhere you want.

Yes, you can store PITFILE anywhere, but:

1) There is single PITFILE that contains all tasks (which means that it would be source of conflicts in all task-related commits).

2) PITFILE contains tasks for all your projects instead of the current one, which means that it isn't really good candidate for storing inside your project's repository. This could be worked-around by exporting PITFILE every now and then, but it's far from perfect.

If you wan to make it useful then I would propose:

1) Store tasks inside git repository (maybe special refs/tasks/* tree? Like for tags or notes: refs/tags/* , refs/notes/*).

2) Store each task in separate file, that is: .git/refs/tasks/001, .git/refs/tasks/002, etc.