Hacker News Reader

Comment by ktpsns | Hacker News Reader

Well, the "why" is certainly "because you use git from the command line; no context switch; CLI is always faster then GUI".

And of course these reasons are poor and hide the fact that with systems like Github (Gitlab and Bitbucket are the same), issue tracking and thelike are locked in. I only know the wiki which can be accessed as git repository (at least in Gitlab and Github). Which other Github "collections" are exposed as git repository?

View on HN

I'm not convinced that their ad-hoc curse interface is really faster than GUI. First you have commands like "issue view" that... open the browser to display the issue. Then you have commands like "pr create" that seem to ask for tile and then description. What if you want to amend the title while you type the description? Well I guess you can always "preview in browser" when you're done. Might as well just do it from the browser to begin with honestly.

"pr checkout" is the only command that seems truly useful and a time saver to me.

Add this to your global git config `[alias]` block:

    cpr="!f() { git fetch origin refs/pull/$1/head && git checkout FETCH_HEAD; }; f"

`git cpr 207` then checks out PR #207.

Thanks for the feedback. There's also a --preview flag in the view commands if you want to see the body in your terminal. We're still working on a bunch more functionality, and we intend to add more flags to allow you to customize the things that are most useful to you. But we wanted to get this in people's hands early to get feedback to help inform where we go from here.

How else would you do it? "Random bozos can open issues" is a desired characteristic, so should they get commit access?

The best you can hope for is to make the issues readily exportable in a standard CSV format. Does it already do this?

Reply on news.ycombinator.com