Vincent Driessen

Oh, so you mean that the command should first pull in new commits from origin into develop before actually rebasing against it locally. Good point! I'll keep this one open.

I've slightly changed the ticket title to better reflect the issue.

I'd like to find a solution for this problem. There has already been some discussion on the topic, I may say. To read up on it, please see http://groups.google.com/group/gitflow-users/browse_thread/thread/9920a7df3d1c4908

Actually, this is as-intended. `mkmodule -p` behaves like `promote` when the module path already exists, otherwise creates it. I've added an explicit test case for this, to express this intent....

As another example, this is pretty much the same logic as it applies to the following scenario: ``` console $ mkmodule foo.bar $ echo "print 'Hello'" >> foo/bar.py $ mkmodule...

Ah, I see what you mean now. Yep, this should be fixed. I'll look at your patch tomorrow.

See the section "Considerations for jobs" on http://python-rq.org/docs/ for more info on this.

Seems like a good idea to let workers always send these events when jobs complete. Or at the very least, make it the default. (If they push an event out...

@kennethreitz That's definitely a plan. Are you suggesting to replace the whole pop-then-fork model inside the worker? gevent definitely is promising. Any suggestions on supporting either multiprocessing or gevent?

Both have their areas of usefulness. Roughly, multiprocessing is better at CPU-bound jobs, while gevent will profit from I/O heavy jobs. Building a clean API (so only little documentation is...