I really enjoy how the author broke down both the problem and the solution, explaining why the existing solutions are inadequate. I often see articles about new products or new programming languages, and their features, but they often forget to mention what problem prompted the solution. Why was a new language invented to solve this problem? Why were the existing solutions limiting?<p>Bravo to the author here for making all that information clear and up-front.
I use hub[0] to accomplish some of the same things. `hub fork` creates a fork and sets up a new remote. After pushing to my fork, `hub pull-request` creates a pull request.<p>[0] <a href="https://github.com/github/hub" rel="nofollow">https://github.com/github/hub</a>
<p><pre><code> then you watch the code, create a branch:
git checkout -b `bugfix/nasty_one`
</code></pre>
Please remove backticks from the command. What if you called the branch `poweroff` instead and a naive reader copy/pasted the command into her terminal?
Cool but 'repo' is a really hard name to search.<p>There's already a tool by this name and they have the same problem.<p><a href="https://code.google.com/p/git-repo/" rel="nofollow">https://code.google.com/p/git-repo/</a>
I really like that this works for all services interchangeably. Yes, Github created Hub for this same problem, but I've used Bitbucket at some jobs and Gitlab personally for some projects. Having something uniform and service agnostic is great. It's clear the creator thought a lot about this design feature.
This is wonderful. I'd guess that this little tiny bit of extra friction is enough of a disturbance to the workflow for private local/personal/work projects to prevent many from bothering to contribute back in some cases (I'm definitely guilty here).
> The git utility has a rather well designed interface to make it easy to remember, extend, and/or customize<p>> (which nobody does, because who remembers the git remote syntax?<p>I wish we would move on from the "git has good UX" narrative, it's preventing us from <i>actually</i> improving the UX.
The name is slightly problematic as Google also released something with the same name: used for Android to solve the issue with multiple repositories instead of submodules.<p>Besides that, looks interesting and I will give it a try!
Goood, I'd really like to try it out. I'm tired of opening the browser go to my fork and create a branch to make a MR/PR for the project I'm working out.<p>I will really try it out. Thanks!
I'm amazed that nobody has commented yet about how this is a CLI wrapper around web services which are wrappers around a CLI tool. Or is everyone here already too jaded and so used to piling endless abstractions upon abstractions that this is considered normal?<p>How about if people simply accepted patches via e-mail, instead of requiring those obnoxious github pull requests?
Honestly, I just opened the post to find ridiculous things to criticise. But in fact this looks like a valid helper. Sure I don't have the same workflow, but this one seems to work as well. Good work!
I'm surprised Github et al. haven't tried to contribute some functionality for doing this to git. The thing described in the article is extremely common.