GitHub CLI 1.0 • Hacker News Board

Re: GitHub CLI 1.0

#151

Post by jrochkind1 » Thu, Sep 17, 2020, 7:58 PM UTC

0xmohit wrote: post #129

Wonder if this would lead to the end of hub https://hub.github.com >.

hub was also a github project. Somewhere there is a blog post or something explaining the relationship of this to hub -- basically, they wanted to start over with new architecture and new thoughts, and a more clear organizational commitment to it (even though hub is at `github/hub`, it is github-owned code).

There is no particular plan to phase out hub, but once github CLI covers enough features, I'd expect people to switch over to it.

Re: GitHub CLI 1.0

#152

Post by cycloptic » Thu, Sep 17, 2020, 8:00 PM UTC

Klonoar wrote: post #149

chadly wrote: post #144

Earlier quoted context omitted.

This is a tired take. Can a company not legitimately improve their product/offering without this being accused at them? If you are referring to GH being owned by MS now, it's 2020 for godsake. Can we move on from our fathers' trauma? MS has been damn good lately in support of developers and developer tools.

I get just as tired of reading this take as the next person, but I don't necessarily think we should do away with it - it'd be akin to ignoring history. I personally remain very uncomfortable with how massive GitHub has become and how ~99% of software development happens on the platform.

Looking at the history in the wikipedia article that was linked in the GP post, none of the executives who used that phrase are with the company anymore.

Re: GitHub CLI 1.0

#153

Post by jrochkind1 » Thu, Sep 17, 2020, 8:00 PM UTC

sigwinch28 wrote: post #111

akx wrote: post #107

Earlier quoted context omitted.

I'd been using `hub create` for several years now...

I'll admit that the only time I heard of the GitHub CLI was last week when I thought to myself "it's really annoying going to the website every time I just want to push a new repo"

I use the older `hub` for only one command, but it's not that one! Instead, I use it for opening a PR from the command line. Since my work generally consists of making feature branches and PR'ing them, I use `hub pull-request` sometimes multiple times a day. Huge time saver.

Re: GitHub CLI 1.0

#154

Post by rasengan0 » Thu, Sep 17, 2020, 8:03 PM UTC

SergeAx wrote: post #126

Watch those hands, we are at the "extend" phase [0]. Then there will be bait-and-switch move, and voila, Github is not working with git client, just with their own shell. [0] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

This may be relevant: https://news.ycombinator.com/item?id=24420307

Re: GitHub CLI 1.0

#155

Post by Kalekoa » Thu, Sep 17, 2020, 8:08 PM UTC

DvdMgr wrote: post #19

mroll wrote: post #16

Oh wow this is great. I’ve been wanting an org mode integration with GitHub for a while, and this tool might make it easy enough for me to hack together this weekend. Basically I want to be able to pull up a buffer with a list of issues assigned to me and copy them into my org mode todo list

You can do this using Forge within Magit already! And it also works for Gitlab: https://magit.vc/manual/forge/

Yes! Thank you for this tip

Re: GitHub CLI 1.0

#156

Post by croo » Thu, Sep 17, 2020, 8:09 PM UTC

Great news but my first thought was that it's hard enough for juniors to grasp the difference between git and github. Now they will be even more confused... :]

Re: GitHub CLI 1.0

#157

Post by clon » Thu, Sep 17, 2020, 8:10 PM UTC

clon wrote: post #85

All of GH improvements have become irrelevant for me since they vanished one of our repos. No notification, no warning, no recourse. Just gonsky. It was just a simple library we wrote to talk to a public IP2Country REST service. Pushed to GitLab, end of.

Cannot edit any more, but it is important to clear this up. Apparently the repo did not vanish, it was deleted by a member of the team, who decided to keep silent about it for some reason.

Tip - there is a "deleted repos" section in GitHub UI where they will appear, apparently with an option to restore them.

In short - all I said seems to have been nonsense. Apologies!

Re: GitHub CLI 1.0

#158

Post by bloopernova » Thu, Sep 17, 2020, 8:13 PM UTC

chungus wrote: post #82

DvdMgr wrote: post #19

Earlier quoted context omitted.

You can do this using Forge within Magit already! And it also works for Gitlab: https://magit.vc/manual/forge/

Been meaning to try Forge, thanks for the reminder. Honestly, Magit alone is enough reason to use Emacs. Projectile is a close second for me.

Can you recommend any good articles or howtos on Forge and Projectile?

Re: GitHub CLI 1.0

#159

Post by sixstringtheory » Thu, Sep 17, 2020, 8:18 PM UTC

machello13 wrote: post #40

GiorgioG wrote: post #37

Earlier quoted context omitted.

Git GUIs simply don't provide the power/flexibility the CLI provides without introducing a UI with a gazillion options. I've tried many (GitKraken, Tower (paid for it too!), SourceTree, VS's integration) and I've always gone back to the CLI.

Depends on how well-designed the app is. GitUp has been my go-to for years, after trying almost every other app out there. It offers a bunch of powerful features exposed mostly through right-click menus and single-button shortcuts. The only reason I ever go to the command line (and I used to be a religious command-line-only Git guy) is because GitUp freezes on extremely large diffs, which one of my projects has a lot…

GUIs are discoverability nightmares though, as you describe. CLIs are the only place you can do a “man git | grep thing”. On macOS there’s ⌘ + ?, but that has never covered all the content in a man entry for the related CLI, IME.

Re: GitHub CLI 1.0

#160

Post by whatgoodisaroad » Thu, Sep 17, 2020, 8:21 PM UTC

chadly wrote: post #144

SergeAx wrote: post #126

Watch those hands, we are at the "extend" phase [0]. Then there will be bait-and-switch move, and voila, Github is not working with git client, just with their own shell. [0] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

This is a tired take. Can a company not legitimately improve their product/offering without this being accused at them? If you are referring to GH being owned by MS now, it's 2020 for godsake. Can we move on from our fathers' trauma? MS has been damn good lately in support of developers and developer tools.

To me, this isn't a real counterexample, even at the height of MS's EEE, it was never at the expense of developer tooling, it was at the expense of openness. In fact, improving developer experience was the primary lever MS used to achieve it.