Live data from Hacker News

GitHub CLI 1.0

github.blog

71–80 of 221 posts

Re: GitHub CLI 1.0

#71

Hmm, anyone know the name of the font they're using in the pictures? Closest I was able to find was anonymous pro, but that's not quite it

The monospace font in Apple's San Francisco family, SF Mono. https://github.com/lionsharecapital/lionshare-desktop/tree/m...

Ah yeah, so it is! Good eye :)

Re: GitHub CLI 1.0

#72
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…

Official CLI tools make it much easier to build automation with shell scripts.

One example that comes to mind - we used hub to hack together a quick security feature that errors out our CI/CD pipeline (which runs shell scripts) if there are any open PRs that are labeled "security" (i.e. Dependabot opening a PR to update a vulnerable library), which forces developers to keep their dependencies up-to-date in order to deploy into production.

GUI tools don't work as part of CI/CD pipelines.

Libraries in higher-level languages (e.g. Python) force you to make sure that there's a library for every tool that you work with - if a specific tool is missing a Python library, then you have to deal with that yourself. Shell scripting is much more productive for gluing multiple sets of tooling together, as long as the shell scripts remain of a maintainable length.

Re: GitHub CLI 1.0

#73
post #25

Earlier quoted context omitted.

That to my knowledge is server-based.

It does not require a server to run.

Thanks, then I will give it a try, when I had looked on the web page the last time I got the impression it was a server based application and required an account on their servers.

Re: GitHub CLI 1.0

#74
post #19
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/

Now this is awesome.

Re: GitHub CLI 1.0

#76

Is there an advantage to using this over the standard git cli tool? It seems kinda like making a cli tool for a web interface for a tool. I guess I'm just missing something. Edit: Spelling.

Yes, you are missing. This is GitHUB cli, not git cli. This has nothing to do with git.

Re: GitHub CLI 1.0

#79
post #41
post #23

Earlier quoted context omitted.

Besides the obvious advantages of command line user interfaces for a lot of use cases, I am not aware of any really good Git GUI. Can you name any for Linux or Mac OS? Commercial would be ok, as long as it can be installed locally and does not require a server.

On Linux I like using gitg. I think it is "good" in the sence that for the tasks it can do (mostly viewing history) the UI is well though out and simple to use. However, it can't do more advanced tasks so it might not be what you are asking for.

I am using it too for visualizing the history, but the version I use doesn't do pushes yet.

Re: GitHub CLI 1.0

#80
post #23

Earlier quoted context omitted.

Besides the obvious advantages of command line user interfaces for a lot of use cases, I am not aware of any really good Git GUI. Can you name any for Linux or Mac OS? Commercial would be ok, as long as it can be installed locally and does not require a server.

Synvento's SmartGit (commercial)[1] is excellent and fully-featured; uses a license file for registering so I don't believe it requires a server. [1] https://www.syntevo.com/smartgit/

We actually licensed SmartSVN, which was a life saver for its version tree display. For most operations, we tended to use the command line nevertheless.
Post reply on HN