Hub: Wraps Git with extra features that make working with GitHub easier | Hacker News Reader

Hub: Wraps Git with extra features that make working with GitHub easier

github.com

98 pointsloppers9249 comments

I've used hub for a few years, but I find the advice of replacing the 'git' command with 'hub' to be a bit over the top. Security/compatibility concerns aside, it can easily confuse non-experts as to what kind of CLI functionality git itself (vs hub/github) provides.

It's often helpful to know what's actually happening... then add something like hub later as an optimization.

This is a github project, that kind of confusion is to their benefit. People will complain about bitbucket/gitlab missing this functionality (but iirc, at least one of them has their own similar project)

Spot on. I'm also a long time user and also keep hub separate & like to understand when it's acting as straight pass through, enhancing the behavior or doing something that only makes sense in Github's implementation.

I had git replaced with hub a few years back but hub was just way too slow starting up, killing what seemed like git performance.

that's a huge reason why they rewrote it in Go

This doesn't seem to give me a single clue on what it does past the initial change of:

    hub clone rtomayko/tilt

Am I missing something?

Their webpage, https://hub.github.com/ , explains more. It includes the ability to work with github pull requests and issues from the command line, and a few nice aliases for opening up github pages in the browser. hub compare v0.9..v1.0

    hub pull-request
    hub fork # adds remote automatically
    hub create # create GH repo for this local repo

And ability to use GH paths anywhere git takes a URL - clone (as you mentioned), remote add, submodules, etc.

That should be on the front page. Above the fold.

A good thing about this (being an open source project) is that anyone can fix it and create a PR :D

Personally I'd rather see my github integration as a subcommand: 'git hub clone foo/bar', etc.

You could put hub in /usr/local/bin/git-hub to accomplish that.

Should be easy enough to add an alias to $HOME/.gitconfig right?

  [alias]
  hub = !hub

Very nice!

What does this buy you besides having to begin each command with four extra letters?

I'd always be accidentally typing 'github', and also putting spaces in the middle of the URL.

Very nice tool, I use it a lot. But I wish they would do releases more often. The last stable release was October 2016, and it's been actively developed since then.

For example, the "release" command (which is great for using from a Makefile to do an automated release) has lots of functionality on master, but the current release only supports making new releases.

https://github.com/github/hub/releases shows some pre releases. I suspect they'd be stable enough.

They're still old. Newest prerelease is from February.

Ah, right.

I may fork hub tonight and let Travis build a newer version.

Pretty essential if you're working on a project hosted on Github. I primarily use it to make PR's from the command line, but that alone is a huge win.

Maybe its just me, but I would rather have PR functionality in git itself.

Linus, please make it happen :)

How would that work? Besides starting completely new centralized git service to compete with github and co? Anyway, git already has a "pull request" system in the form of git send-email and related commands.

I know Linus probably would not agree but emails aren't a substitute for a pull request system: they're a bandaid to compensate for the lack of one.

I agree it would require additions to git & some kinda of standard around it but it's telling that every major git system in use "solves" this problem.

That system works for Linus since that is how he works. However, it doesn't seem to work for most other people.

We need a system to do this in a standardized that works across service providers. I don't want to create a dummy github account only to submit a PR.

Git already has quasi-"pull request" functionality by a different name.

It's possible to use https://git-scm.com/docs/git-request-pull and an out of band communication tool (Email, Slack) to achieve the same basic functionality. Take a look at https://git-scm.com/book/en/v2/Distributed-Git-Contributing-... for more info about the baked-in review and contributing tools.

Is this similar or how is different/better than gitflow? http://nvie.com/posts/a-successful-git-branching-model/

gitflow is comparing OOP and FP. If git is C then hub is C++. I don't believe you can compare the two. hub just adds some convenient commands to git for working with GitHub.

Different use cases.

Our companies fork of gitflow uses hub for example.

I have used this extensively for interacting with Github.

But definitely, my biggest use is for quickly creating new private repos in Github to save small experiments (doesn't require hub to be aliased to git):

    new => !git init && git commit --allow-empty -m 'Initial commit (empty)' && hub create -p `basename $PWD`

For new projects (hope you can get the aliases):

    mkdir newproject && cd newproject
    g new
    # Do stuff, etc...
    gcia -m "Add project start" && gp

I've been using hub to do update orchestration over a group of repos, i.e. bubbling up updates through a dependency tree, opening respective Pull Requests, linking them among each other, etc.

Previously: https://news.ycombinator.com/item?id=9616239

It doesn't compare with hub, but I wrote gpr to make dealing with pull-requests easier as a maintainer. The main use case to check out a PR on a detached head:

gpr <PR#>

You can also easily checkout a branch from another users fork.

https://github.com/mbrookes/git-pull-request

I use this as my default git command via aliasing, as mentioned in the ReadMe. Paste this in your bash profile to alias: eval "$(hub alias -s)"

Note that this does shell detection and works for most common shells, but your eval may be different.

https://github.com/github/hub/blob/master/commands/alias.go#...

does this help you move around Zenhub issues on your kanban from commit -m "?"

but isnt git pretty much the best thing in the world since it was made by the who who remote linux? Why do u need sugar ontop of it?

Oh wait, thats right, cause guys who make operating systems dont make human software.

I know I shouldn't reply to comments like this, but what are you going to do to make the (software) world better? Git's got warts but it's getting better, and there are alternatives like Mercurial if they work better for you.

A comment that states the obvious? Im merely pointing out the power of the OSS hype-machine.

Like it would make sense to me if everyone who used git also used VIM, but they dont. Its a testiment to the power of the flock, that a product which gets its core functionaly so wrong, be used by so many ppl.

as for the topic at hand, if my company had invested so heavily into such a product, i would be doing everything in power to make it work. let alone if my companies core business was all in on it like github, it would be a no brainer and i cant beelive its taken so long to get the top of the backlog. looking forward to the nxt installment of hub which introduces propriority commands and see if they get treated like MS does :)

It's all about the ROI for GitHub - git works well enough for them.

If a problem in Git was causing a problem for GitHub I'm sure they'd work to fix it. Although I don't see any @github addresses in git's git.

c.f. https://github.com/libgit2

There certainly are github employees who contribute a lot to git, but not with their github e-mail address, but with their personal address.

You realise MS uses git and github internally right?

But hey if you're a happy TFS customer then good for you...

The issue with git isn't that it has warts or that it's not improving - it's that it's a cli tool with bad and confusing defaults. Because people use bash for programming, the cli interface is basically an API now. So we can't change it because it would break peoples bash ci/cd scripts. That's why git is bad for humans: because it's kept backwards compatible in order to be good for computers.

I keep arguing that the unix model of using the same api for human consumption as for scripting is broken. One needs to be concise and doesn't need to be backwards compatible (interactive use), the other needs to be descriptive and backwards compatible (sctipting use). Git wasn't designed in the 70's so could easily have avoided this.

> bad and confusing defaults

Compared to what? It's leagues better than what it replaced (SVN & CVS) and it's pretty comparable to Hg tbh.

So what's your preference here?

> Compared to what?

Compared to how it would work today if it wasn't constrained by backwards compatibility, and it was designed for ergonomics rather than power. Every time a best practice changes, or a new default is considered best practice, or you notice a typical usage pattern means a particular command is much more common - then the interface should reflect it. There have been multiple wrappers such as this one - but there could be room for a big official cli tool that is not backwards compatible (want to script? - call git directly).

> It's leagues better than what it replaced (SVN & CVS) a

Git as a tool is better than svn and cvs - but I don't agree its interface is. This is of course an unfair comparison since svn, cvs etc is so much simpler (It's after all a LOT easier to make a good UI for a ToDo app than for facebook). The best comparison for an UI of a "modern" vcs is git vs mercurial.

I find mercurial (I referred to that above as Hg) to be more or less the same as Git. Their CLI commands are very very similar.

What specifically are you complaining about here?

I think hg is more consistent, more polished, and sometimes involves a bit fewer steps to accomplish the same tasks.

One of the best (and funniest) criticisms of the git command line is the famous git koans. http://stevelosh.com/blog/2013/04/git-koans/

git branch -d

git remote rm

Is a prime example of how, if you designed it from scratch, you wouldn't leave inconsistent. "List things", "delete things" etc are activities that should work the same for all kinds of objects. the Git cli isn't designed with that thought. It's organically grown and every change is more or less irreversible because the human interface UI is used in programming (What I like to think of as the biggest flaw of Unix)

Wtf is "human software"? And by the way, what's wrong with adding sugar on top of a low level system? Do you program with syscalls? I bet linux must be a pretty shitty software since it requires so many libraries and abstractions for "humans" to be able to work with it.

Reply on news.ycombinator.com