

The project manager from hell (integrates with Git) - smalltalk
https://github.com/michaeldv/pit

======
yogsototh
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.

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

~~~
epochwolf
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.

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

~~~
jacquesgt
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.

------
yuvadam
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.

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

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

~~~
piotrSikora
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.

