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.
Such negativity here. I wonder why it still surprises me.
@qw3rtman: This is a great idea for a project. Making Git's UI more accessible and attractive is a worthy goal. Keep at it, I'm sure many people will use this.
For example, the gg s command presents you with an easy to look at a quick glance status of your repository. In addition, there are aesthetic changes that increase the intuitiveness of Git itself.
Sure it's not exactly an alias, but this is basically just splitting the usual `git status` output and coloring it. I have similar functions in my .bash_profile for git and it doesn't require node. Consider this: I can easily scp my dotfiles to a server and use all my shortcuts. To use this I have to install Node, npm, and this package to gain a couple of new shortcuts that make existing functions a little prettier.
Your .bash_profile functions probably aren't exposed to others via a package manager. They're probably not available in a repo for others to contribute to either.
Yes, node/npm are required, but most of the servers I work with these days already have those for other tools.
Mine are, but that’s because I’ve published my .dotfiles for everyone to use. What I haven’t done is made them usable by anyone who isn’t using my dotfiles. That wouldn’t be that hard to do, I just need time to develop infrastructure around it (which is probably worth doing anyway because my dotfiles are feeling a bit creaky).
EDIT: Scratch that. I just saw that git-config supports include directives. The infrastructure is already done for me. Now I just need to separate that bit of code out of the main dotfile repository.
Pairing git-config's include directives with a separate semver-tagged repo for your Git code sounds reasonable.
I guess what I was getting at here is that I haven't come across a good analog to npm for shell scripts or dotfiles "modules". Using node/ruby/py/etc instead of shell scripts is often overkill (debatable for gitgoodies), but having the standardized infrastructure is valuable.
I'm concerned with the lack of feedback about _which_ changes are staged + commited. It should be considered best practice to review what you are committing.
This looks nice although personally I'm a happy user of scm_breeze[0]. My favourite is the shortcuts which allow you to interactively enter a commit message in the shell without needing to open an editor.
I felt very jumpy looking at the output of `gg s` -- what's staged? What are the changes? What am i going to commit? Maybe it's for people who routinely do `git commit -am $MSG` but sometimes it's best to be a little more nuanced. But i'm a complainy geezer who likes magit.
It's important to know the basics of git from the command line but git's output can be so rich that it's pretty futile to try and capture this from the command line.
Even if you ssh a lot, the odds of having these extra layers installed are pretty low so you might as well get as comfortable as you can with the basic commands.
But for local usage, do yourself a favor and install a graphical client. Color terminals will never give you as much information as a graphical tool will.
OMZ is a nice tool for new zsh users to get a sense of the shell's capabilities, but it also comes with a lot of excess that doesn't really seem fit for regular use. The idea of a plugin system is great for desktop environments, browsers, and even editors, but it seems strange to me to use one for your shell.
Personally, I prefer a more minimal shell setup, so I decided to develop my own customization from the ground up based on the ZSH User Guide (http://zsh.sourceforge.net/Guide/zshguide.html) rather than installing a large chunk of additional code and plugins that I'm unlikely to be able to carefully evaluate, in addition to memorizing others' mnemonics.
For those who prefer to evaluate something just from the end-user perspective and don't really care about how it works as long as it does work, I could understand the appeal of OMZ because it offers a lot and asks little in return.
Here are some other discussions from reddit about OMZ along this same general theme, which I would encourage prospective OMZ users to read as well:
It would be nice to have something that makes the hard-to-remember stuff in git more accessible. @qw3rtman, how often do you plan to work on this? I wouldn't use it yet, but I might if it were more built out (and had support for branches).
I'm glad these make your life easier, but I'm not sure why anyone else who already knows how to use git and can make their own aliases would bother learning yours.
> Yet another testimonial that something is wrong with Git UX :)
I'm not going to debate whether git's UX is good or bad, but I don't feel like this is much of a testimonial to that. Bearing in mind that git and bash's aliasing capabilities implement the short-aliasing side of this project, (as just about every other comment in this post mentions), such that "git" can be aliased to "g" and "status" to "s", most of his examples seem to either output needless output ("Fetched!"), or output less than the original command (gg status), or are otherwise quite similar. An alias for clone seems like an odd example — the original command is 4 keystrokes longer; what's gg add here?
It might be good to show in the README how each example is materially better than git's default output, because I'm just not seeing it.
The only output I didn't fully design on my own was the log command (`gg l`). I used information found on this Gist (https://gist.github.com/textarcana/1306223) to retrieve the log information in JSON. From there, I designed an output style on my own.
EDIT: I partially retract my previous judgement, the prettified and colorized output does look nice.