It's also pretty easy to extend and the team who maintain Salt are really friendly and accepting of patches/pull requests.
We do strongly encourage squash commits so I wouldn't go by counts alone, but pick what tool you like to use most and that best fits your needs, and your style, and what you want to do with it.
I'd really appreciate a deeper comparison, though - especially if you feel that there are certain areas/circumstances where ansible may shine over salt.
http://news.ycombinator.com/item?id=5244740
Main thing on Ansible is the focus on multi-tier and process orchestration, without having to rely on coding up event paths between nodes -- admittedly it's a niche problem, but to me, deployment is as important as config management, and often harder. That being said you can write deployment in anything if you try hard enough, but I built what fit my brain and the particular needs of a few past companies deploying multi-tier web apps. While it is easy to have ad-hoc in the product (Puppet also does this with mCollective), it's a bit harder to be able to both model deployment and declarative state, and then make that into content you can hand over to a security auditor who doesn't know the language and he can say, yep, that's exactly what we want.
* More commits in github. * More pull requests in github. * Main website is ranked higher by alexa.
However, after using salt for a short while, I ran into a couple of problems (no mercurial state, no ability to specify versions when using a pip state), which ansible seemed to be able to handle.
So, I don't know... salt seems to be more popular. A bit. That's all I can tell.