git_remote_branch is github-agnostic
Josh Knowles recently suggested that maybe I could merge grb’s functionality to the github gem.
Both gems being command-line tools that help you use Git in a friendlier manner, the question makes a lot of sense. It makes so much sense in fact, that I decided to blog about it. A post about it will scale much better to answer other users who may potentially ask the same question.
So here’s a slightly edited excerpt from the answer I gave him. And yes, I also ramble in email.
I’ve seen what Scott added to the github gem. Pretty cool stuff indeed. I think the idea of merging with the github gem has merit. I definitely can see a future where we start having too many distinct command-line tools that help deal with Git’s sometimes obscure or numerous commands.
However I’m not sure I’d like to merge grb into the gh gem, despite the additional awareness it would get. Here’s why.
In my mind, the github gem should be mostly features about GitHub itself, like managing pull requests (the way GitHub does them). It’s starting to accumulate features that probably aren’t GitHub-specific, which I don’t mind, of course. But grb’s features really are GitHub-agnostic. I’ve started working on it before I even started using GitHub, in fact :-)
Reinforcing the previous point, I wouldn’t want someone who doesn’t use GitHub to not realize the features of grb are available to him because they’re included in a gem called ‘github’ ;-)
Also, one of the goals of git_remote_branch is to explicitly teach the underlying git commands. I do this by always spewing out the underlying commands in red, and by having the explain command. I’m pretty sure an unsuspecting user would wonder what hit him if a few of the github commands started spewing out red text in his console ;-) Having explain for a few commands (ported from grb) and not for the rest of the github gem’s commands would be weird, too.
There’s also a few other architectural decisions of grb that may not fit with github’s, like having aliases. Once again, grb being a teaching tool, I want to offer a bunch of aliases for forgetful people like me. So far I don’t see anything like aliases in github and I’m not sure how the authors of github-gem would react to a pull request polluting it with a bunch of aliases ;-)
Last but not least, the github gem already has a track command, which conflicts with grb’s. github’s is used to track a new remote repo in your local repo while grb’s is to track another branch from your current remote repo.
So git_remote_branch is GitHub-agnostic. You can use it with any Git hosting solution: GitHub, your own Gitosis / gitweb / Gitorious installation, Gitorious.org hosting, Rubyforge or any other.
Better, grb supports working with all of them at the same time. All grb commands support an optional origin argument.
git_remote_branch 0.3 – Awesomeness for the masses
Awesomeness for the masses
git_remote_branch 0.3 has been released!
Previous releases were pretty much only usable by rubyists on OS X.
No more. This release is mostly focused on making sure git_remote_branch works on a broader range of platforms. A few actual features squeaked in, but nothing big like introducing new commands.
If you don’t care about the details just type the following at your command-line.
sudo gem install git_remote_branch
And check the help
grb --help
If you encounter installation problems, refer to the readme.
Platforms
git_remote_branch 0.3 has been tested with the following configurations:
- OS X Leopard / Ruby 1.8.6 / Git 1.5.4.3 and 1.6.0.2
- OS X Leopard / Ruby 1.9.1 / Git 1.5.4.3 and 1.6.0.2
- Ubuntu Intrepid Ibex / Ruby 1.8.7 / Git 1.5.6.3
- Windows XP / Ruby 1.8.6 / Git 1.6.0.2 (the msys version)
Features
Better track
Track now works even if you already have a local branch of the same name. It uses git config instead of branch —track in that case. The subtlety can be observed by running (from a git repository):
grb explain track master
grb explain track non_existent_branch
Force the use of a specific git executable
Set the environment variable GRB_GIT to point to it and grb will use this one for all its operations.
Documentation
I’ve also worked quite a bit on the actual documentation. I used to be ashamed at the quality and availability of the documentation of git_remote_branch. At last I’ll be able to sleep at night :-)
git_remote_branch in a nutshell
I’ve rewritten the intro of the readme to be (hopefully) a bit clearer.
git_remote_branch is a simple command-line tool that makes it very easy to manipulate branches published in shared repositories.
It achieves this goal by sticking to a few principles:
- keep grb’s commands extremely regular (they all look alike)
- support aliases for commands
- print all commands it runs on your behalf in red, so you eventually learn them
Another nice thing about git_remote_branch is that it can simply explain a command (print out all the corresponding git commands) instead of running them on your behalf.
Note: git_remote_branch assumes that the local and
remote branches have the same name. Multiple remote
repositories (or origins) are supported.
Documentation availability
The main readme is now available on the main grb page on rubyforge.
Documentation quality
I’ve added clearer information on getting grb to run in different kinds of situation, due to helpful feedback from Axelson and Glenn Rempe.
I’ve also added some information for playing with the code for git_remote_branch (test dependencies and so on). See the end of the readme.
Finally, I’ve updated the links section quite a bit:
| Documentation | http://grb.rubyforge.org |
|---|---|
| News | http://programblings.com/category/git/git_remote_branch/ |
| Bug tracker | Lighthouse |
| Code | http://github.com/webmat/git_remote_branch |
| Mailing list | http://groups.google.com/group/git_remote_branch |
Dare
I dare you to find a platform on which git_remote_branch doesn’t work :-)
If you do, please send me feedback through GitHub or via email. I’m using gmail and, as usual, I go by the handle of webmat.
Last note: the git_remote_branch gem on GitHub
Excerpt from the readme:
Note that the only stable version of the gem you should trust is the one from Rubyforge. The GitHub gem is a development gem. The GitHub gem WILL be rebuilt with the same version number, and other horrible things like that. If you use the GitHub version of git_remote_branch, children will die!
You’ve been warned.
I don’t know about you, but for me, using git is so low-friction that I use it basically for everything where I may need a powerful undo button. In other words, I don’t use it only for team software development projects.
For example, I’ve frequently used it in the past to keep track of the modifications I make to an article I work on for few days. God knows I write a lot of these. There’s a reason I called this blog Programblings ;-)
To be honest, I’m using git as I write even this short article.
I also use it for trivial one evening coding projects. As soon as I spend more than an hour on code, whatever it is, I’ll usually create a local git repo for it.
One of the annoying things I realized when creating repositories more and more often, is that I always ended up ignoring the same files. Over and over again. Boring.
Fortunately for me, git can be configured to take into consideration a global ignore file. Heck, I can even create a system-wide ignore file if I want (check out git config’s doc for more info).
Configure your personal ignore file
I like to stick to conventions so I call my file .gitignore, and I put it in my home directory. But that’s up to you, really.
git config --global core.excludesfile ~/.gitignore
Note that there’s one little gotcha to be aware of. If you prefer to edit the .gitconfig file directly (or if you use a weird shell), git expects an absolute path. In the example above, bash converted the ~ shorthand to my home directory.
Now I just add ignore globs to it like any other project level (directory level, really) git ignore file.
echo .DS_Store >> ~/.gitignore
Once I’ve ignored all my favorite useless files, I can get cracking and never worry about them again.
I still have to ignore files
When I create a new repository on which people may actually contribute, I’ll still create a proper ignore file, however. Otherwise I’d convey the message that I consider contributors as slaves who only deserve the boring work of creating ignore files. Since I’m pure of heart, that’s not how I roll.
I can’t believe I hadn’t taken the time to try out qgit yet. Check this out:
Install qgit from source on Leopard with these instructions.
Warning: installing the Qt 4.3 prerequisite takes an eternity or two (instructions for that are included as well).
Also note that you should make sure to use the newest versions of the downloads: the instructions point to an old 2.0rc1 release of qgit.
git_remote_branch 0.2.6 is out!
I’ve just released a new and improved version of git_remote_branch. Code named 0.2.6!
Ok, I admit. I haven’t really begun using code names.
I’m promoting the project from a pre-alpha to an alpha release. There’s still a lot to do, but the stability and “testedness” have improved greatly. Following are both sides of the maturity story.
The project is maturing
- grb got its first contributor, Caio Chassot
- I added a lot of tests, both unit and functional
- there might even be interesting stuff to see in there for those who need to test command-line tools
- the gem can now be installed directly from RubyForge
- git_remote_branch now has a Google Group
The project is still immature
- it swears a lot
- no rubyforge page, despite the project being on rubyforge (at rubyforge.org/projects/grb)
- no real documentation other than running grb help
- very little in code documentation. On the other hand the code is spectacularly clean and readable, so that’s completely unnecessary. Just kidding.
What’s new in 0.2.6?
Three new actual features
- the ‘rename’ command, contributed by Caio Chassot
- the ‘publish’ command
- the −−silent option to completely mute grb output as well as every git command run by grb on your behalf
And other stuff
- the grb bin file now works when symlinked (also thanks to Caio Chassot)
- lots of unit and functional tests
- bug fixes
- more flexibility for running grb outside of a git repository (e.g. for ‘explain’ or ‘help’)
- now officially under the MIT license
- refactored a bunch of rake tasks
Git the new version
To install the newest version of the gem, simply run
sudo gem install git_remote_branch
If you really want to be on the bleeding edge you can also get it on GitHub. Note however that in ‘bleeding edge’ the word ‘bleeding’ is still the most important one at that point.
git clone git://github.com/webmat/git_remote_branch.git cd git_remote_branch rake install
The ‘install’ task will run the tests before installing so you’ll need Shoulda, mocha, redgreen and ruby-debug for that approach.
Not familiar with git_remote_branch?
What it is
The basic idea for git_remote_branch is to trivialize the interaction with remote branches. The first goal is to make the commands for the simple situations easy.
The secondary goal, is to help you learn the commands by seeing them displayed in a beautiful shade of red each time you use grb, along with git’s output.
git_remote_branch lets you
- create local-remote branche pairs, and tracks the remote branch automatically (for automatic merges when you git pull)
- publish a local branch as a remote branch, very similar to create
- delete local-remote branch pairs
- track a remote-only branch
- rename a local-remote branch pair
- explain by simply spitting out the necessary commands to do any of the above
How to use it
explain
If you simply want to use grb as a cheatsheet (and run nothing on your behalf), you can use the explain command:
$ grb explain create
git_remote_branch version 0.2.6
List of operations to do to create a new remote branch and track it locally:
git push origin current_branch:refs/heads/branch_to_create
git fetch origin
git branch −−track branch_to_create origin/branch_to_create
git checkout branch_to_create
or
$ grb explain create my_branch my_origin
git_remote_branch version 0.2.6
List of operations to do to create a new remote branch and track it locally:
git push my_origin current_branch:refs/heads/my_branch
git fetch my_origin
git branch −−track my_branch my_origin/my_branch
git checkout my_branch
Notice that you can specify any normally expected parameter you’d normally include and ‘explain’ will use them in the list of commands it suggests.
Even better, if you’re in your repository, the current branch is going to be taken into account:
(master) $ grb explain create my_branch my_origin
git_remote_branch version 0.2.6
List of operations to do to create a new remote branch and track it locally:
git push my_origin master:refs/heads/my_branch
git fetch my_origin
git branch −−track my_branch my_origin/my_branch
git checkout my_branch
Of course, ‘explain’ works for all commands: create, publish, delete, track and rename.
The main commands
I’m not going to painstakingly give an example for each command. I’ll only give two, to show how git’s responses are displayed when running grb without ‘explain’:
(master)$ grb create test_branch git_remote_branch version 0.2.6 git push origin master:refs/heads/test_branch Total 0 (delta 0), reused 0 (delta 0) To git@github.com:webmat/git_remote_branch.git * [new branch] master -> test_branch git fetch origin git branch −−track test_branch origin/test_branch git checkout test_branch Switched to branch "test_branch" (test_branch)$ grb delete test_branch git_remote_branch version 0.2.6 git push origin :refs/heads/test_branch To git@github.com:webmat/git_remote_branch.git - [deleted] test_branch git checkout master Switched to branch "master" git branch -d test_branch (master) $
Yes my friends, I have just boldly used grb on my real repository for your viewing pleasure.
But worry not, no repository was hurt during the writing of this article.
Feedback
For any feedback you’re of course welcome to
- comment on this article
- post in the google group
Thanks
- To Caio Chassot for the code contribution
- To the Thin team for a good inspiration on how to help manage gem creation and deployment with rake;
- Feedback from James Golick in day to day collaboration as well as all the people that commented on the initial announcement of git_remote_branch;
- To Chris Wanstrath (defunkt) from the GitHub team for pimping of the initial announcement of grb on the GitHub blog.

