New commands: star, unstar, follow, unfollow.

[mlang]

These features are not usable with simple web browsers on github.com.
This is my accessibility workaround.
Adds star, unstar, follow and unfollow as subcommands to hub.
Repo/user info is either taken from the current repo or from the command-line.
See my posting about github accessibility issues
(http://blind.guru/contributing-on-github.html) for my motivation.

[hkdobrev]

👍

[3flex]

Should be unfollow I think? Likewise on line 350.

[mlang]

Matthew Haughton notifications@github.com writes:

+### git star
+

• $ git star [user/project]

• (star current or specified project on GitHub)

+### git unstar
+

• $ git unstar [user/project]

• (unstar current or specified project on GitHub)

+### git follow
+

• $ git follow [user]

• (follow owner of remote "origin" or specified user on GitHub)

+### git follow

Should be unfollow I think? Likewise on line 350.

Thanks for catching this, squashed and fixed.

CYa,
⡍⠁⠗⠊⠕ | Debian Developer URL:http://debian.org/
.''. | Get my public key via finger mlang/key@db.debian.org : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 . ' - URL:http://delysid.org/ URL:http://www.staff.tugraz.at/mlang/

[mislav]

Hi, thanks for liking hub a lot.

Historically I rejected all similar PRs and feature ideas because hub was always only a git wrapper, and wouldn't implement parts of GitHub API functionality that has nothing to do with git workflows, like stargazers/watchers.

In the future this might change, since hub is becoming a more generic GitHub API tool. However, I still don't think it's very useful to have this sort of functionality on the command-line, since I imagine people usually watch/star people or projects during exploration of new projects, which usually happens in the web browser and not on the command-line.

@jingweno @technoweenie What do you think—where do we draw the line about the functionality we'd want in GitHub CLI?

[technoweenie]

I would agree that hub should stay a git wrapper. I thought the releases command was a bit much TBH.

[mislav]

The releases command is tied to git tags, so I still see it valuable as part of a git workflow. However, for this (watching/starring) I don't feel strongly about.

@mlang I'll reject it for now since we're not prepared to support & maintain these features. And in the future, new features won't be written in Ruby: #475

[hkdobrev]

@mislav Do you think in the distant future you could support easy extensibility. It is really easy to add new commands to git. So instead of having a separate CLI tool for GitHub API features like start/unstart/follow/unfollow, these could be just some hub commands in a separate repo.

[mislav]

@hkdobrev I'd love to support that. A hook system of sort. No idea how it would actually work, though.

[owenthereal]

There's a simple plugin-in system built in to the Go heroku CLI. We could take a look as an inspiration. Basically it shells out to another program with inherited environment variables.

[mlang]

Mislav Marohnić notifications@github.com writes:

In the future this might change, since hub is becoming a more generic GitHub API tool. However, I still don't think it's very useful to have this sort of functionality on the command-line, since I imagine people usually watch/star people or projects during exploration of new projects, which usually happens in the web browser and not on the command-line.

I understand your thinking, however, my particular problem is that I am
using GitHub with a Non-JavaScript browser right now, and
starring/following does not work for some reason. Trying to invoke
these gives me a 404, and no status changes. I simply wrote this
feature such that I and other blind GitHub users could easily
participate in these aspects of GitHub. Hub is really not just a git
wrapper to me. Hub is the reason why I stayed on GitHub. Some of the
GitHub workflow is so modern-HTML that I am not able to use them
comfortably. Since I found Hub, I have an actual reason to use GitHub.
If you reject this, I will have to maintain my own branch and maybe
advertise it for those that need the feature. Given that it is really
just a few lines of code, this seems a unnecessary hurdle to those few
that actually rely on that functionality. And, I actually don't fully
agree with your workflow description, since I personally never use the
source code viewing capabilities on the web. If I stumble across a
GitHub hosted project I find interesting, I "hub clone" it, and look at
it directly on my filesystem. If I find it interesting, a "hub star"
perfectly fits a hub-savvy users workflow, me thinks seriously.