GitHub CLI 1.0 | Hacker News Reader

GitHub CLI 1.0

github.blog

663 pointstodsacerdoti212 comments

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/

I've been using Emacs for a decade and still have never had to write a single package of my own. Every time I have a good idea, someone else has already implemented it.

Consider donating -- if you're a software engineer, acknowledge the value of your own time!

I donate little bits here and there when I can, but I'm unfortunately not in financial position to give what I think the maintainers deserve. Instead I try to submit documentation patches to projects whenever I find myself digging through the source code trying to answer a question the docs didn't make clear.

That makes you a solid contributor in my book!

I've written a few specialisms that couldn't really be open-sourced. e.g. wiring up inf-ruby and internal dev tools to open up a rails console in dev, or generate a jwt from the auth server in the cluster.

The only package I've been ultimately responsible for is the Gruvbox theme[^1], but that was very quickly handed over to other emacsers :)

I still find it a joy to write and it's one of my more preferred rabbit holes to dive into. Maybe one day there'll be something more to share :)

[^1]: https://github.com/mrleedev/emacs-gruvbox-theme

Oh wow, I used to use that theme. Thanks for making it. Yeah, most of the elisp I write is mostly just glue code, not something that makes sense to package and distribute.

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.

I find projectile too chatty and distracting none thing I like about emacs is that I can focus on what I’m working on.

In what way do you find it too chatty? That hasn't been my experience, but I do use a pretty small subset of it. Are you using it on its own, or with helm/ivy?

It could have been hel or ivy I was seeing. I don’t like the mode line moving (growing the minibuffer) as I typically keep my eyes on part of the buffer and don’t want anything moving (or worse, obscuring where I’m looking)

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

I switched from Emacs to VSCode but I still use Magit to do rebases.

Now this is awesome.

Forge is great. Magit is such an enjoyable plugin already, but integration with PRs and issues takes it to the next level.

Haha of course this already exists! Thanks a lot for the pointer, I will for sure start playing with it this week :)

This is awesome, but with all due respect I also wish git itself was also improved.

Goddamn merge commits, and always have to go googling "oh shit how do I erase the last commit" when I accidentally commit to master. It should at least spit out a warning if you created a branch and then try to commit to master. Git lfs and git-crypt should be a feature of the main product and not plugins. Files over a certain size should be transparently LFSed without some need to "track" them or install a plugin to fetch them. It's too hard to accidentally forget to encrypt something or LFS something. Gitignore is easy to screw up and accidentally commit a sensitive credentials file. And "git rm" also removes the file locally with no recourse -- that should not be the default behavior.

Also, the whole UX around submodules REALLY sucks ... is it git submodule update --recursive --init? git submodule init --update --recursive? git init submodule --recursive? I can't remember for the life of me. Why can't it auto-clone all submodules when you clone the parent repo, seeing as you kind of need them to do anything? The UX is so bad that I often just copy the contents of the repo instead of using submodules.

There are "hooks" in git that can be used to modify its behavior, to e.g. "spit out a warning if you created a branch and then try to commit to master"

This seems to be a good resource https://githooks.com/

> "spit out a warning if you created a branch and then try to commit to master"

How this one may be done? It sounds wonderful but I have no idea how to implement such thing (and if not included in git already, I hope that I can reuse code rather than reimplement it)

Oh, hey now. Look at the very bottom of the resource I sent you, under "Snippets" https://githooks.com/

"A pre-push hook that prevents direct code push to master branch"

and I would want

"spit out a warning if you created a branch and then try to commit to master"

Sometimes I would want to commit to master, I want an overridable warning iff I just created branch.

How about

  #!/bin/sh
  BRANCHES_POINTING_TO_HEAD=$(git branch --contains HEAD  |wc -l)
  CURRENT_BRANCH=$(git branch --show-current)
  if [ "$BRANCHES_POINTING_TO_HEAD" -gt 1 ]; then
    if [ "$CURRENT_BRANCH" = "master" ]; then
      echo "You're committing to master even though other branches exist."
      echo "override with git commit  --no-verify"
      exit 1
    fi
  fi

You'll need git 2.22 for the --show-current git option.

But also I would suggest instead using

  git checkout -b <new_branch>

to create and switch branches in one command

A better UX would be

    $ git checkout <new_branch>
    <new_brach> doesn't exist. Would you like to create it (Y/n):

The real problem with "git" is just way too many options. For automated tools there can be a "-n" non-interactive option that fails with an error code and doesn't ask questions.

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.

Azure Repos and maybe Pipelines be sunset and replaced by GiHub equivalents, but they’d have a hard time sunsetting the task management (Boards) without first significantly expanding it in Github. Many swear by their hierarchical backlogs, custom column Kanban boards and complex reporting. GitHub issues is extremely simple in comparison.

They're rolling Planner and Tasks into Teams, I fear they may try to substitute that and Power Bi for DevOps Boards.

Zenhub[1] is a pretty popular UI on top of GitHub that fills that need quite nicely for my team

1 - https://app.zenhub.com/

Never heard of Azure Repos before. Do they have any unique features that could be merged into Github?

I believe that Actions was a port from Azure DevOps (https://azure.microsoft.com/en-us/services/devops/?nav=min) so it does seem the teams are working together to improve the products.

IIRC it was Azure pipelines.

When reviewing PR, it has nice file/folder tree on left side, which is far superior compared to scrolling over 10+ files without context on Github, I hope Github gets this soon...

There's a browser plugin called Octotree which does a pretty good job of this, but I'd prefer it to be builtin.

Bitbucket has it as well. When you move from Bitbucket to Github your PR workflow in the WebUI feels utterly complicated and way harder to review. I already started to use gh a few month ago and that finally puts some sanity into working with github. Beside of creating PRs and merging them you can also get the diff of the PR, and pipe it to other tools. In the most simplistic case into diffstat. That finally compensates a bit for the horrible WebUI experience. Still a tree view would be nice.

I like that it works with Active Directory, so I don't need my developers to setup their own GitHub accounts to work.

And Golang is killing it for these kind of applications.

I haven't done much beyond dip my toes in Golang so far, but I did start moving my blog over from Jekyll to Hugo last week; Man do I love just being able to install a single binary and then get to work. Python, Javascript, and Ruby have a lot of nice packages, but I always have to futz around with the language itself to use them effectively. It's probably a bit easier to get a project up and running in a scripting language, but any development time that is saved just gets passed on to the users as we have to install a ton of npm packages or try to fix our gem dependencies.

Are dependency problems with Hugo modules not possible?

I'm sure there are, but I haven't needed to use any modules so far, so I have no perspective on what kind of challenges they present. But with Jekyll you could get into dependency issues just trying to go through the tutorial and launch a blank template of a site. You didn't need any extra functionality on top of Jekyll to begin to dealing with dependencies.

I was wondering if this was written in Go, and specifically using the Cobra framework. I checked out the repo and it was!

Other common CLIs written with the same framework: kubectl, hugo, rclone (to name a few)

Really is a great option.

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... :]

That's the point

To be fair, they’re not explicitly saying to alias it as `git` this time. At least with a different name the distinction is clearer

I have never really grokked the concept of git to push or pull, commit or diff the code that I write. Tried to convince myself a few times that is best practise from the industry. I still tgz my source code before I intend to make substantial change.

Github for me is simply a repo of open source code that I can inspect before I use someone else library.

Source control is well worth the learning curve. Git is harder to learn than most, though. I hear Mercurial is easier to learn; maybe give it a try?

Isn’t mercurial pretty much dead? I know Bitbucket dropped support for it last year. I’ve also found it no more intuitive than git personally.

What about https://hub.github.com/ ?

Check out https://github.com/cli/cli/blob/trunk/docs/gh-vs-hub.md

FWIW gh is built by some of the same people that built & maintain hub.

Thanks. I think this info should become part of the blog post IMHO

Hey, thanks for sharing. I was wondering about hub vs GH.

I use `hub sync` multiple times per day. Essential tool.

It's the only way to stay sane in a repo with multiple other developers merging PRs. Updates all of your branches in the background to the current remote version.

Damn, I should RTFM, 'cause that sounds super useful!

For the time being, hub still mostly helps with git operations, in fact it can be used as a git wrapper/replacement since it supports all of git’s commands.

gh on the other hand seems to very specifically work on GitHub’s non-git features, like Issues, PRs, repositories.

IME for non-git features hub is very slow iirc it's written in Ruby

hub has been pure Go for a long time now.

I've used ghi before just for issues:

https://github.com/stephencelis/ghi

It's pretty nice. I like seeing these features supported officially (I think hub supported many of these unofficially for years).

What tools are there like this for Gitlab? I remember struggling just to find a decent CLI for their issue tracker.

All my new stuff is on Gitlab and I prefer Gitlab since if I ever want to, I can always just management my own instance and migrate to it. No such options with Github.

If you use VSCode they have a pretty decent extension (GitLab Workflow)

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 by sticking to the cli, other than this misplaced notion that it's what the cool kids are doing.

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 detailed diffs etc.

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.

It's worth installing the CLI just for a single command:

`gh pr create --web`

Saves me having to push my current branch, navigate to the repo page, hit the "create PR" button, etc.

These days when I push a branch, github gives a URL in the response that I can click from the terminal to open a PR. It is indeed very good.

That is pretty nice.

I've been doing `git push -u origin HEAD` and then using my mouse to click on the "go here to create a PR" link that gets printed, which isn't too bad. Takes you right to the page where you can review the changeset before opening the PR. If I'm not actually ready to open a PR by the time I push upstream, I just open a draft instead.

Yes, that's what I do as well. I also have the old hub frontend for git installed. The idea is that you simply alias git to hub and then you get a few extra commands.

My favorite is "git browse", which opens a browser for the current repo & branch. There are a few other commands that are probably useful but that I don't really do much with.

This is one of my favourites, too! And combined with the alias functionality, you can do

    gh alias set pcw 'pr create --web'

and then just use

    gh pcw

to create a new PR. There's also sufficient smarts around forking or not, depending on write permissions on the upstream repo.

Do you run this command frequently enough to do an alias? I feel like it'd be better to just have the muscle memory of typing the actual command instead

Probably a few times a day? One nice thing about the alias is that it expands and takes more parameters if you want, like

    gh pcw --base=development

It's also super quick to set up an alias, so I don't see why not.

I used to have a lot of git aliases but then I became dependent on those and forgot the actual git commands that were lying underneath. So whenever I went to a new system I'd have to port my dotfiles or look up the git docs for what the commands were. If a colleague asked me "how do I do X" I had no clue and had to look in my bashrc. Nowadays I only add them if I do it many many times per day. Like "git commit -a -m" for example. I try to keep things as close to stock as I can

This type of alias seems on the fence for me, if was like 10x a day I'd definitely be on board but a few times a day is a gray area

Yeah this is huge— I used to use `hub` for this one thing as well. The alternative is even worse if you cloned from a repo you don't have push access to, so your first step is going to the web UI, creating the fork, switching the remote on your clone, and then _finally_ pushing and creating the PR.

Thanks for this, will start using it.

This is the main reason I'm installing - I can build this into my editor pretty easily.

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.

There are a bunch of examples which I find very useful with the CLI: Creating new repos (gh repo create), opening the repo in the browser (gh repo view), checking out PRs when you have the ID (gh pr checkout ID), diffing the currently checkout PR against the base (gh pr diff).

It has nothing to do with being a cool kid. No two people are the same. How you best process information may not be how someone else best processes information. Neither is right or wrong they are just different Everyone deserves to have tools available which fit how their brain best processes information.

If you are not on Linux, please try Fork. It's plenty fast and very robust, I have fallen in love with it on first sight.

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.

Yeah, CI solutions can use this command instead of having to write and maintain their own github API interfacing, for example.

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

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.

The things you mentioned are better when presented visually. Visual representations leverage the visual processing system of the human brain, and for graph-like data are near-objectively superior to linear textual representations.

However, you can approximate visual representations of these things in a CLI - `git log --graph --pretty=oneline --decorate --abbrev-commit` will use ASCII characters to draw the DAG of commits.

Moreover, the GitHub web GUI is not "amazing". It's tolerable as far as web UIs go, but it's missing a lot of keyboard shortcuts (and none of them are customizable), has no built-in extensibility (the fact that you can inject your own scripts and stylesheets is a hack only at the display level, and an impractical one at that), EDIT: isn't scriptable, and is incredibly resource-intensive relative to a native application. The GitHub CLI allows you to manage the non-git parts of GitHub from the command-line (and make your own GitHub native client by extension) - which is desirable, given the above.

gitk comes with Git - it's not perfect but it beats ascii art.

I don't think the GH web interface is even tolerable. Even Bitbucket, which really sucks, has a better one...

Without a CLI you can't automate. (I guess you could, but it will be a pain in the ass)

There was the option to use curl and the GitHub API, but the CLI wraps that very conveniently in the "api" subcommand.

Huh? Github actions have been around for over a year, and Github webhooks since I can't remember when.

Not really sure what you're talking about. Not everything you automate on GitHub happens in the context of a CI pipeline like in GitHub Actions. There are many cases for small scripts where you just need to execute a couple of commands.

Yeah, and this is the correct way to automate anything relating to github. Their API is insane.

...unless you use their CLI wrapper over the API (as in this post) :)

I've never felt the need to visualize git scenarios; they just aren't all that complicated most of the time, though I can see how it might be useful to open a graph viewer if you have a tricky merge to sort out.

For me, being able to just note down in a text file an exact trace of what I've done is the gist of why CLIs are superior for my use. How do you even begin to keep track of what you do in a GUI? You could record video, but the information density is way too low for it to be useful, and it's worthless for automation.

A lot of my stuff gets automated by me first doing stuff manually, recording what I do in a script, and next time just running said script. That's just flat out not possible with most GUI tools, and even if it were, it's too cumbersome to be worth doing.

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 of.

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.

> 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 to grep which lets you focus on specific information you care about.

2. Memory - I can write aliases to help me remember my common workflows.

3. Automation - I can have a script check PRs for me. This reduces context switching and enables greater focus and productivity.

Speed and overhead are both areas that should get a lot more focus nowadays; the Github desktop app along with a ton of other applications are Electron / webapps, each one adding a number of always-active processes, complex and expensive rendering, script execution, and a ton of memory usage, which do add up over time. I mean a lot of developers will have two or three Electron apps open right now; Slack and / or Discord, VS Code, Notion, and a bunch more in their browser of choice.

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.

a CLI is scriptable and automateable, so there's that at least. How about "find all related issues and close based on the commit message and push to production if it's an urgent fix" etc

I have to agree. I used the CLI for years until a coworker showed me Githubs desktop app. I was hesitant at first, but it makes managing multiple projects so much easier.

It's more about automation than about end-user (developer) UI. CLI gives you a simple way to automate tooling for your team's processes (simpler than writing code to call into REST API's), and it's code, so you can maintain it as code and not some set of configurations on a UI somewhere.

Probably because the GUIs are always missing something.

today I wanted to see the commit history and changes of a single file. I tried for 20 minutes to figure how to do that in sublime merge some of that searching online. Failed. Used the command line like I probably should have in the first place.

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.

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.

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.

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.

SourceTree is very good and free. I use it for:

1. Selecting specific lines for a commit. 2. Stashes management 3. Rebasing branches, cherry picking commits.

It is possible to do a lot more with it, but for the most other operations I use command line or GitHub UI.

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.

vscode with ‘git graph’ extension is the best git toolset ever.

My favorite feature is ctrl+click 2 nodes in the git tree and immediately see file level diff which I can explore in vscode’s diff viewer.

For work, we use git flow with github PR (which I do on github website) and always work in feature branches. I am able to navigate git like a pro, cherry picking etc as needed without a problem. It even works well with git submodules.

If something goes unexpected, git graph is the best tool to figure out what happened and to be able to repair it.

Also, vscode handles merge conflicts in a way I can actually understand and correct without it slowing me down.

I like GitHub desktop

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.

Scripting and shortcuts are very useful. To each their own but doing repetitive tasks in a GUI is prone to errors and boredom

What's amazing about the Github web GUI?

It's not utter garbage (at least not yet).

I'm not sure this is the case! In fact, I strongly suspect that its inability to display logs or diffs correctly has contributed to the widespread developer confusion with respect to Git, especially since there are many people out there who think, implicitly if not explicitly, that Git and Github are one and the same.

You know how a lot of people think merge commits (an important keystone in how easy Git makes it to read and write meaningful history) are inherently "confusing" or "messy", and try to avoid creating them? Well, if you look at them in Github's awful log interface, they sort of are! This doesn't seem like the fault of those developers, and it's not Git's fault, since it ships with powerful command-line and GUI tools for making sense of things.

cli should be the basis of everything.

There can be UI and sometime that's helpful, but all action contained therein will be available on cli, just because that's exactly what the UI calls.

VS Code does everything Sublime Merge does, for free

This is worth it just for `gh repo create`

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.

Ah, but now you can `gh pr create` instead! Saves four keystrokes.

But by the way, `hub browse` and `hub sync` are handy too.

It's all the same to me if it works, it's easy to switch the one command I use, I'll probably switch to `gh pr create`, since it appears to be the more maintained package. `hub pull-request` does a few things that annoy me or that seem buggy, maybe I'll compare to `pr`.

I never did use `hub` as a "wrapper" for `git`, I've always typed `hub pull-request`. I never liked the wrapper idea. So I approve of `gh` abandoning it.

agreed

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

CLI or not, it's centralized/siloed all the same. I'm sticking to Git.

It would be really nice if the other features of github could get into the decentralized model of git... I could imagine issues and PR reviews/comments all being mini-commits to some kind of parallel metadata repo under the hood for example.

Have a look at fossil https://fossil-scm.org/home/doc/trunk/www/index.wiki

Or maybe git-appraise https://github.com/google/git-appraise git-bug https://github.com/MichaelMure/git-bug

And recently discussed here https://radicle.xyz/

There are some experimental tools for distributed code review and issues.

https://github.com/google/git-appraise

https://github.com/dspinellis/git-issue

Would be nice to have something more polished though.

Just make ForgeFed a reality, and then it won't really matter where the project is hosted. :)

https://forgefed.peers.community/

Good point.

It never seemed like the distributed "selling point" of Git (and Mercurial et al) really caught on. I remember trying to extoll it's virtues to our team at the time (pre-Github). No one source of truth as such, just everyone swapping changes as needed. It's kind of ironic that Git's most popular incarnation is based upon a centralised model.

Is it just a case of the distributed workflow just not being that useful for most people? Beyond the obvious example of Linux kernel development, of course!

I think in practice it's most useful as a recovery feature. I once got locked out of my Bitbucket account and had to recover a repo, which I'd been paid to develop, from Heroku of all places. I was extremely grateful at that point that all git repos are complete mirrors of each other.

It is also useful that you have full access to repo when internet is unavailable.

Distributed workflow is still plenty useful, but the master copy being hosted by GitHub doesn't really affect it all that much. The real benefit was the ability to clone a repo and just start working on it locally - with commit history, branches etc - and then tidying it up and merging it back upstream when possible and convenient.

Are people forgetting what life was like back in SVN days, when not having a connection to the server meant not being able to do many operations?

Reminds me of React -> React Native -> React Native Web.

Can we expect -> GitHubCLIHub which simplifies using the CLI with a website?

GitHubCLIHubCLIHub which simplifies using the GitHubCLIHub's CLI with a website

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).

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

They do not treat hub as an official github project and rather an unofficial open source project that they don't plan to do away with

They have a document where they expand on this: https://github.com/cli/cli/blob/trunk/docs/gh-vs-hub.md

To highlight from that doc:

"The GitHub CLI team is focused solely on building out the new tool, gh. We aren’t shutting down hub or doing anything to change it. It’s an open source project and will continue to exist as long as it’s maintained and keeps receiving contributions."

Farther along in same doc:

"hub is a project whose maintainer also happens to be a GitHub employee. He chooses to maintain hub in his spare time, as many of our employees do with open source projects."

My experience at FANMAG has been that "spare time" is the scarcest of all resources.

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.

I think the creator of Hub works for GitHub, possibly on the CLI IIRC.

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.

> GitHUB cli

So a wrapper for an API for a website for git? Why?

Edit: Also, how does anything working with GitHub have nothing to do with git?

Edit 2: Don't get me wrong, this looks like a cool tool. I'm just curious about the motivation.

Github provides additional functionalities over git for which users had to switch from cli to web. Now they are bringing those additional functionalities to cli so users dont have to switch context

Ah, that makes sense then. Many thanks.

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.

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.

There isn't much lock-in yet though. If you wanted to move a project from github to gitlab, you could move the code over with a few commands. Open issues and stuff could be moved over with a script. There isn't much 'network effect' that means your project would die on other hosting.

This is classic "it could be built in a weekend" syndrome, and I think we're all intelligent enough on this site to know that it's simply not true.

Furthermore, technology isn't the lock-in - it's the network, which you can't drag as easily.

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.

Subtract the bare assertions and questions and your argument boils down to "it is $current_year, and Microsoft has been good lately." Which, I think you might agree, doesn't contain a lot to convince someone who remembers the bad old days.

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.

How do you know the difference between being in an EEE scenario versus just being in a scenario where people keep working on their product?

When the open components that allow free interoperability with GitHub's competitors are replaced with proprietary components that don't.

Did that happen?

Just look at history.

Does that mean it _always_ happens? Or only sometimes?

I think the simple way of passive resistance is calling it "Microsoft GitHub".

Good idea, gonna use it, thanks!

And in a few iterations they will label git as "legacy".

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

And wait until they claim it is to "improve the user experience" because they care about their users so much they need to protect them from the free and familiar tools they are used to.

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 :)

I tried it but couldn't get it to push my commits. Reverted back to GUI Github.

I'm a n00b though, might just be because I'm dumb. But when they have actually dumbed down the CLI and spent time and resources to make it so user-friendly, shouldn't they have went thorough with it to make it as intuitive as Github Desktop?

Does something like this exist for bitbucket too?

I’d be surprised if bitbucket’s dev tooling budget was 1/10th of GitHub’s even before the MS acquisition.

Working with BB APIs has not been fun at any point in the past 5 years or so :(

BitBucket has a sane API. But it might be a case for a 3rd party os solution...

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!

I find in situations like these that it's pretty unlikely that the person telling the story really has no idea why something bad happened to them.

You are right. I have a hunch. In the local repo there is a file that was was probably produced by running wget github.com im the repo directory. Unsure what it was meant to achieve, but accidentally pushed, it may have flagged the repo down somehow. Maybe the HTML contained some secret token?

Still, the main issue was the process how they handled it. Your build breaks. This is how we found out.

Martin from GitHub here - love to understand what happened if you have the time to point me at more details. DM's open (martinwoodward on twitter and martinwoodward at github.com on email)

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.

Do you know whether the poster with a GitHub issue ever bothered reaching out to Enterprise support?

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".

I will send the repo URL in a few hours. Thanks for following up.

Clearly not that irrelevant if you're in here commenting.

Should qualify that. I never said it doesn't sadden me to miss out on cool things. But professionally they are indeed irrelevant.

I love this tool and use it everyday. Thank you Github and contributors.

I tried it today, and it's pretty neat, but without the ability to write comments inline, it's not super useful for any actual pull request reviewing work.

I agree. I wrote a tool that does inline PR commenting on the command line. I hope they add something like this to gh over time.

https://github.com/jordanlewis/re

Good they have the Enterprise server support now. Time to try it now. I had to some hacks to use request-pull with the GitHub's process.

Can you also browse the code with this? Find a file? Find only within xml files? Copy a link to a specific line? Create gists?

You can create, edit, list and view gists. You can't copy a link to a specific line (afaik). As you run this tool from your project directory you can browse and search code using your tools of choice.

It's an excellent tool even if you just use it to quickly create and view PRs and issues, as I do.

name me one feature this has that I didn't have 3 years ago with `hub`?

Very nicely done. The package installation process for Ubuntu is good. Thank you.

Finally, pull requests from the command line without git arcana.

Embrace - complete

Extend - in progress

Extinguish - todo

Extend

Or git, as it's known.

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.

It's not a replacement for git, its to interact with the GitHub UI over the command line.

There are 3 main commands from the CLI you can issue:

  gh

  CORE COMMANDS

   issue:      Create and view issues
   pr:         Create, view, and checkout pull requests
   repo:       Create, clone, fork, and view repositories

I still use the git cli and the github UI, but sometimes just view open PR's from the my terminal if I'm already in there.

Honestly the doc make it pretty unclear.

Some commands seem to be purely github related, which make sense, some others seem to overlap with just plain git.

> Clone the repository you want to work with using gh repo clone owner/repo

Like, what does this do apart from a regular git clone? Why is this necessary? I guess it additionally stores some meta information so that other "gh" commands know which repo they are on. This should have been a separate command IMHO to leave the regular git clone alone. Something like "git clone ssh://github.com/foo/bar" followed by "gh init foo/bar".

> When you’ve finished adding that feature or fixing that bug, use gh pr create

Same goes here. Why overlaying git commands? I would have expected to just push my branch, and then call something like "gh pr create <my branch> <target branch>"

> And your teammate can check out your pull request using gh pr checkout 1337

Same remark again and again, what does that do apart from checking out a branch? Why the overlay?

> view the diff with gh pr diff

So what's wrong with "git diff <target>..<source>"

> gh pr merge

Come on.. "git co <target> ; git merge <source>" needs to be overplayed?

> gh release create [tag name]

Oh sure, let's overlay git flow as well.

I mean overall the tool looks cute and all, but magic overlays is a no no for me.

Convenience.

> Like, what does this do apart from a regular git clone? Why is this necessary?

You can't see a difference between ```gh repo clone owner/repo``` and ```git clone git@github.com:owner/repo.git```?

Also:

> Something like "git clone ssh://github.com/foo/bar" followed by "gh init foo/bar"

What's there to "init"?

> Same goes here. Why overlaying git commands? I would have expected to just push my branch, and then call something like "gh pr create <my branch> <target branch>"

From the docs: "When the current branch isn’t fully pushed to a git remote, a prompt will ask where to push the branch [...]"

> Same remark again and again, what does that do apart from checking out a branch? Why the overlay?

It resolves the pr # to the corresponding branch name, probably git fetch and checkout. Why should I have to know the irrelevant piece of information that is how you named your branch?

> So what's wrong with "git diff <target>..<source>"

How do you find out the target and source hashes? Another piece of convenience.

> Come on.. "git co <target> ; git merge <source>" needs to be overplayed?

And this is wrong. This merges source in target locally, ```gh pr merge``` merges it remotely. You can be Linus Torvalds, you are not going to push to my master branch.

No, is a complement. See [0]. Basically allows doing from cli things you could only do from the UI before (without writing your custom scripts).

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

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.

I don't understand this mentality. Git itself doesn't provide a way to interact with PRs or issues on GitHub.

This utility does.

If you are uncomfortable with using GH to manage issues and PRs you shouldn't probably shouldn't be using GH.

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

It seems like this is not a CLI for git, but for the Github specific stuff, such as issues and pull requests.

How you could create issue with git? Project on github is much more that just git repo

Yeah, I wonder if `git` could be improved based on this.

Reply on news.ycombinator.com