I agree that the node dep is somewhat of a turnoff, but besides that, I'm not quite sure who the target userbase for this project is.
I think Git users largely fall into two camps: hobbyists that use Git primarily because of Github and probably use less than 10 Git commands (I'm in this camp), and professionals who rely on Git heavily, and have been using it long enough that they've likely tailor-made their own shell aliases/functions/scripts to meet their exact needs.
The first group has little use for a host of aliases that they'll likely never need, and the second isn't inclined to trade in their own tools for colorful output that depends on node.
It's an interesting idea, but I just don't see it taking off.
If you really want it in Node, it should be refactored to use node bindings to the libgit2 API instead of exec(). Using exec() the way you currently do introduces synchronous code. In reality, this would be much simpler in pure shell w/o the node dependency :)
It differs from python in that node is being used in this project, not python.
If the project used python it would be equally perverse.
As for why? Much of the functionality of this project is aliasing git commands to shorter names, which could be done easily as a git alias, or even a plain old shell alias or function.
Instead, node is invoked, which then uses the child_process module to... shell out to git. It's a pretty convoluted way of doing either `alias ggs='git status` or `git config --global alias.s status` .
Using node, or any other scripting language to transform `foo s` into `git status` seems a bit heavy to me, but then I'm not the target audience for this tool, so there is that.
Having said all that, gg does actually provide a bit more than simple aliases, it seems to do a decent job of prettifying the output from git commands and improving the user experience. I don't wish to discourage the author of this tool. I personally wouldn't use it, but they should feel proud of what they've made and continue hacking and making things.
> Having said all that, gg does actually provide a bit more than simple aliases, it seems to do a decent job of prettifying the output from git commands and improving the user experience.
I wish you had included this in your initial comment, which otherwise seems like a knee-jerk reaction to a misinterpretation of the project's scope.
Personally, I would like to see it include significantly more robust functionality than aliases and prettified output in order to offset the cost of loading up the node runtime. There isn't much to be improved upon with the typical init/clone, pull, commit-all, push loop. Beyond those typical tasks, there's a lot of room for improvement, and that's where something like gg could excel. I would love to see something that helps with merge conflicts, rebasing, history modification, partial/interactive staging, etc.
I think Git users largely fall into two camps: hobbyists that use Git primarily because of Github and probably use less than 10 Git commands (I'm in this camp), and professionals who rely on Git heavily, and have been using it long enough that they've likely tailor-made their own shell aliases/functions/scripts to meet their exact needs.
The first group has little use for a host of aliases that they'll likely never need, and the second isn't inclined to trade in their own tools for colorful output that depends on node.
It's an interesting idea, but I just don't see it taking off.