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.
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
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.
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.
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.
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):
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.
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.
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.
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.
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.
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.
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)
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 often helpful to know what's actually happening... then add something like hub later as an optimization.