Hub: Use GitHub from the Command Line | Hacker News Reader

Hub: Use GitHub from the Command Line

hub.github.com

137 pointsmaxfan834 comments

While it is pretty cool, using such tool increases general lock-in to GitHub, in terms of both habits and potential use of it for automation of processes.

I wish there was an open standard for operations that hub allows to do and all major Git forges [1], including open source ones, such as Gogs/Gitea and GitLab, supported it. In that case having a command-line tool that, like Git itself, is not tied to a particular vendor, but allows to do what hub does, could have been indispensable.

[1] https://en.wikipedia.org/wiki/Forge_(software)

Git remotes is the standard.

Hub is pretty much a glorified ref transformer.

You can do a lot of what it does with plain old aliases and really should if you work with multiple forges.

You're also only talking about a single git use case which not everyone follows, even within a single forge.

Something tackling the problem from the other end is phabricator which integrates each VCS into the same forge platform. Well, mostly (badly), it's kind of a total mess with specific things you need to work around for each.

I can see the same thing happening to anything trying it from the forge end.

Just because gitlab has pull requests does not mean that GitHub born idea is the best or will even stay.

How would you marry up Gerrit to GitHub (you can't).

What you're asking for only really works for something following gitflow, which would be kind of stupid to base a standard on because it's broken by design and doesn't scale. But you would have to because otherwise GitHub won't use it.

There is Lab[1] - similar tool, supporting both GitLab and GitHub. But I agree with your point about common standard.

[1] https://github.com/zaquestion/lab

There is Magit Forge which is not limited to Github https://github.com/magit/forge

If you are not familar with Magit, there is a screencast: Emacs Rocks! Episode 17: Magit https://www.youtube.com/watch?v=rzQEIRRJ2T0

Hub is essential for anyone who works with GitHub repositories, IMO.

It gives you, if nothing else, an important shortcut: `hub checkout github.com/repo/pulls/1234` automatically adds a remote, fetches, and checks out the branch of a given pull request. Great for local testing/validation, when needed.

Or, simpler:

    hub pr checkout 1234

I recently learned that you can do

  git fetch origin pull/⟨PR id⟩/head:pr-⟨PR id⟩ && git checkout pr-⟨PR id⟩

(but hub is nicer of course)

You can do this fairly easily with a git alias without needing to be locked into a GitHub-only client:

    [alias]
    pr = !"pr() { git fetch origin pull/$1/head:pr-$1; }; pr"

And then do `git pr 1234 ; git checkout pr-1234`. Feel free to add `git checkout` to the alias if you prefer.

I might be missing something, but can’t you just `git checkout -b <feature-branch-name>`?

Not if the branch is on a fork.

Ah gotcha, then that is a pretty handy shortcut.

Slightly tangential: I keep seeing Linuxbrew references on various tool installation instructions. Is Linuxbrew really gaining popularity? Why would you use it instead of your distro package management?

Maybe among Mac-to-Linux converts or simply because it’s easier to get your package into than multiple Linux distros. There’s more control for the packager that way.

Admittedly a Mac-to-Linux convert here, but what I like about linux/homebrew is the ability to build the very latest version of the requested package on the day of the release. Distro package managers make living on the bleeding edge more difficult.

I use Arch Linux, whose motto could be "living on the bleeding edge" (maybe combined with "annoying install process"). This even with the included package manager. But with Debian derivatives, you can add Debian testing to your apt configuration to get newer packages.

Aside: I think "old" packages (~1year) actually protect you from a few bugs and make some sense on servers, but I wouldn't hesitate to use Debian testing on a desktop.

> Why would you use it instead of your distro package management?

Linuxbrew can[1]:

* Install software to your home directory and so does not require sudo.

* Install software not packaged by your host distribution.

* Install up-to-date versions of software when your host distribution is old.

[1]: https://docs.brew.sh/Homebrew-on-Linux

I wrote something like this called git-admin[1] for remotely managing repositories and the like.

[1] https://github.com/ninetynine/git-admin

I use Hub every day! The only command I use is "hub pull-request" though.

I only use hub to create a repo. I think there are probably quite a lot of people who only use one command in it.

Me too, plus `hub merge $PR_URL` in order to merge PRs locally with the same commit message as if I had pressed the "Merge Pull Request" button on GitHub.

I do this in order for the merge commit to be signed.

I have only use 'hub browse' aside the twice I used the form command.

As I mentioned in another comment[1], you can create a simple git alias which does this for you so you can do everything from git without needing a GitHub-specific client.

    [alias]
    pr = !"pr() { git fetch origin pull/$1/head:pr-$1; }; pr"

[1]: https://news.ycombinator.com/item?id=20374136

And I only use hub issue to sync my issues locally. Just updated hub two days ago, because the old version failed. It's still very unreliable though.

Hub is pretty cool. I've used it to automate the release process on github by writing a simple bash script.

Does anyone know if it is possible, using hub, to sync a personal fork, with its upstream?

I use hub, but almost exclusively to clone a repo, or more frequently, create a pull request (being able to specify a base branch to)

Uhm... Why not just use git for that?

Less typing.

Anything existing that does similar for gitlab?

https://github.com/zaquestion/lab

Anyone see the irony that its for gitlab, but posted on github?

So what does it do that git doesn't? Without answering that, it feels awkward to put forward a CLI frontend to a CLI tool.

Awesome. I've needed something like this since the beginning of github.com itself. I can now, with glee and joy, chuck all the lame curl scripts I was using/maintaining to try to perform the same function, and use something better.

The only thing is, I don't like the name. The use of the term 'hub' is a bit dangerous - I know other tools out there named such. For me, it'd have been better to have named it something more specific/unique to the intended purpose, like 'ghub' or even better, 'github-client', and then leave the alias-to-simpler-word up to the end user.

> The only thing is, I don't like the name.

That ship has sailed. This tool has existed (and been popular) for years.

Fair enough, didn't know that, thanks for the info ..

Reply on news.ycombinator.com