Live data from Hacker News

GitHub CLI 1.0

github.blog

21–30 of 221 posts

Re: GitHub CLI 1.0

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

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.

Re: GitHub CLI 1.0

#24
post #23
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…

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.

I use GitKraken, it is great!

https://www.gitkraken.com/

Re: GitHub CLI 1.0

#25
post #24
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.

I use GitKraken, it is great! https://www.gitkraken.com/

That to my knowledge is server-based.

Re: GitHub CLI 1.0

#26
post #2

Is this proof that regular git commands are too difficult to use? I also wonder what this is going to do for folks not using Github as now CLI users are going to "unlearn" all their traditional git commands.

No doubt the intent of this tool is to tightly couple your development flow to GitHub/Microsoft. Makes switching to other vendors more painful further down the line.

That's a fairly cynical take. How is this any worse than offering an API?

It's open source [0], there's nothing stopping you hooking it up to Gitlab, or pointing it at jira.

[0] https://github.com/cli/cli

Re: GitHub CLI 1.0

#27
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.

Indeed, a project I work on has a release script which tags a release and all and currently uses a third party tool for the GitHub interactions. Now we can use the first party GitHub CLI commands instead.

Re: GitHub CLI 1.0

#28
post #25
post #24

Earlier quoted context omitted.

I use GitKraken, it is great! https://www.gitkraken.com/

That to my knowledge is server-based.

Thanks to the one downvoting me - what in my comment justifies a downvote? If my statement is wrong, I would certainly be interested in a correction.

Re: GitHub CLI 1.0

#29
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... understood when presented visually Often true for me as well. I like `tig`. > What use case is better served by sticking to the cli? Good question. Knowing the "why" of things is important. My answers: 1. Focus - Opening a browser and clicking around takes more patience. It tempts me to go update my company's internal documentation about something irrelevant to my current task. A CLI lets you pipe things…

1. Can be addressed by using a GUI which is not on the internet, for example SourceTree, the git interface in IntelliJ, probably many more.

2. Is often unimportant if the GUI tool can make common workflows one or two clicks.

3. Having the CLI tools to automate stuff is great, but is not necessarily the best way to have an interactive session with a repository.

Some of the things I like about graphical interfaces for Git:

- The information density is usually (depending on the program) great - I can see local branches, remote branches, commits and tree diagram for the selected branch, all in less space than a terminal usually takes up.

- A bunch of actions are available by right-clicking on a relevant item, so I don’t have to remember commands and command-line flags etc and I can just get on with things.

- Some actions like “show me the diff between these two commits” are SO much easier that they become a viable way of working.

Re: GitHub CLI 1.0

#30
post #10
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…

How about when you already do most of your development on the command line? In web development anyway, most frameworks, servers and tools are CLI only so you are already on the command line for the most part. It's far quicker to do a quick commit there and then rather then move to a GUI. That said, I use both. Most of my commits etc. are on the CLI but I still switch to a GUI if I want to browse the repo or see more…

Exactly this. I use the GitHub CLI and website interchangably throughout the day. When making commit messages, I generally always link a commit to an issue. So the end of a commit message will generally say "Resolves #281" or "Fixes #433" or "See Issue #218" or whatever.

I usually need to double check open issues when making these messages and since I am already writing commits on the command line, having a split terminal or tab that can pull up active commits with a single line command and see them in a concise and clean format, it is super helpful and fast.

If you are already working in the command line all day long, then it makes perfect sense to have access to GitHub in the command line as well.

Another benefit is that most IDEs will have direct terminal access within the IDE, which means you can get relevant GitHub details about your project from within the IDE via the terminal, without needing to leave the IDE.

Lastly, the CLI version is far more concise and simple compared to the web version.

I am not hating the web version. I still use the web version plenty. But it is just another useful tool in the quiver that has plenty of use cases and simplifies workflow.

Post reply on HN