

Manage GitHub Issues with the command line - sassyalex
https://github.com/stephencelis/ghi

======
niggler
When GitHub is down, the thing I actually miss is the issues. You can't seem
to clone them. Are there any public issue trackers that can be easily
replicated?

~~~
drhayes9
Have you seen ticgit? <https://github.com/jeffWelling/ticgit>

All the tickets are kept in a branch within your git repository. It offers a
Gem-based CLI, "ti".

It wasn't quite as frictionless as I like my issue trackers to be (especially
for personal projects), but it does what it says on the box.

------
joelcox
I've been using `ghi` for quite some time now and I'm definitely a fan. One
feature I'd love to see is offline-mode because I often work on some personal
projects during my commute.

------
XorNot
This would go great with Hub (<http://defunkt.io/hub/>) which provides pull-
request integration.

~~~
amichal
so does ghi.

------
orta
I have a similar gem but for pivotal tracker: <https://github.com/raul/pt>

~~~
jamesbritt
I suspect this is something everyone feels compelled to do.

For github I wrote ghissues: <https://github.com/Neurogami/ghissues>

But ended up not using it (forget why) so it's likely way out of date.

For Pivotal I wrote Pivotal Slacker; that was in 2009; Github ended up hosing
the repo somehow, and soon after I stopped using PT.

Anyways, both of these grow out that little voice that says, "I wish I could
do this stuff at the command line. How hard could it be? I'll just write some
code ... "

------
chimeracoder
Unfortunately, this only seems to work on the remote named 'origin'. If your
branch corresponding to GitHub is named something else (ie, 'github'), it
won't work.

Nice work otherwise, though - I've been thinking about writing something like
this for my own purposes in Go for a while now; glad to see someone else had
the same problem.

If I have some time later today, I'll put in a pull request... unless someone
beats me to the punch.

~~~
stephencelis
It actually lets you do this already, though the documentation is relegated to
a manpage that doesn't get installed automatically. It checks, in order, for:

    
    
      - $GHI_REPO env var
      - git config ghi.repo
      - remote named "upstream"
      - remote named "origin"
    

So you can just use "git config ghi.repo username/reponame" to get the
behavior you want.

