Live data from Hacker News

GitHub CLI 1.0

github.blog

121–130 of 221 posts

Re: GitHub CLI 1.0

#121

Is this coming full circle: Git -> GitHub -> GitHub CLI?

I guess GitHub CLI is kind of porcelain for the `git format-patch` and `git am`. Although I don’t know of any git commands that will send or fetch the `.patch` files to the mailbox.

git send-email and git imap-send can send to a mailbox (the latter can be used to upload files to an IMAP folder). I don't know of a command that could download patches from a mailbox (though it would be nice if git provided one that would work with IMAP and/or NNTP).

Re: GitHub CLI 1.0

#122
post #13
post #6

I don't understand the appeal of using a cli to manage commits, branches, remotes, merges with conflicts, and so on. To me all these things are so much better internalized and understood when presented visually. Git GUIs are aplenty (Sublime Merge being my latest discovery, SourceTree before that) and generally really good. Combined with the already amazing GitHub web GUI, it's a wonder what use case is better served…

Better scripting / automation maybe? I don't have any specific example in mind right now, but being able to pipe things together with other utilities could make for interesting applications, and is easier than having to interact with a REST API.

I have an open source project that moved from using Jira to track issues and changes to Github. Before, when the project made a release, it would fetch info from Jira to create a changelog.

With this tool, I was able to do something similar using Github as the source of information instead[1].

I fetch the info using the gh tool, output the result into json, and use a python script to format the output which results in a decent looking automatically generated changelog[2].

It's not the most exciting thing, and I could have probably achieved it in a different way using the GraphQL API directly, but for the needs of the project this fit the bill and let me get on with the release.

[1] https://github.com/aurora-scheduler/aurora/blob/master/build...

[2] https://github.com/aurora-scheduler/aurora/blob/master/CHANG...

Re: GitHub CLI 1.0

#123
post #6

I don't understand the appeal of using a cli to manage commits, branches, remotes, merges with conflicts, and so on. To me all these things are so much better internalized and understood when presented visually. Git GUIs are aplenty (Sublime Merge being my latest discovery, SourceTree before that) and generally really good. Combined with the already amazing GitHub web GUI, it's a wonder what use case is better served…

I largely use the CLI and I still manage conflicts and diffs visually (in plain git), by triggering a visual diff application from the CLI when I prefer doing so.

The GIT cli has the option to use an external diff helper if you prefer.

Re: GitHub CLI 1.0

#124

Earlier quoted context omitted.

This is part of the problem. No recourse for such decisions unless you make a stink about it on an orange website or get enough likes on the website with the blue bird logo.

Probably wasn't a decision. And if it was, I'm sure it's much more complicated than OP is letting on.

Even an automated decision is a decision, because someone decided that's how the system should operate. Perhaps it was a bug?

Furthermore, no: GitHub has a history of being bad at this kind of thing:

https://news.ycombinator.com/item?id=22593595

From the linked article: "A week after I’ve opened the support ticket, GitHub has finally replied. Suspiciously, this happened right after someone important has posted a link to this article on Hacker News"

https://news.ycombinator.com/item?id=22628961

Top comment: GitHub CEO coming in and apologising. From the linked tweet: "You sited US trade sanctions and sent me a non-descriptive email with no remediation information".

Re: GitHub CLI 1.0

#128

GitHub is killing it with these features. I wonder how long Azure Repos will survive on it's own.

We did some training with Microsoft last fall and the coordinator straight up told us that DevOps functionality was being duplicated in Github and that DevOps was being sunset eventually.

He recommended using YAML for all Pipeline Development as they were trying very hard to ensure that it would be compatible but legacy pipelines would not.

Post reply on HN