Gitbox - Everyday git [Mac OS X] interface for human beings(gitbox.pierlis.com)
gitbox.pierlis.com
Gitbox - Everyday git [Mac OS X] interface for human beings
http://gitbox.pierlis.com/
52 comments
Do not underestimate the potential usefulness of a git utility that lets people do a couple of basic operations on a git repo while teaching them nothing. I know lots and lots of people who have no desire to learn version control but who need to interact with a VCS.
But I think I understand where you're coming from. My take is that all of these supposedly-simpler interfaces are nowhere near radical enough. If you try to make git easier by deleting half the feature set you end up with Emasculated Git. It's still obviously git, but it isn't git, so (e.g.) you ask your friend how to use git and they tell you ten things, half of which you can't do because the tool doesn't support them. Or you consult a git book and it seems both familiar and unfamiliar.
What I wish someone would try is designing a tool that has, say, 5% of Git's features, and a different name, but uses Git's protocols to interact with Git repos. The user presses a button to download a project from a URL. They tinker. Occasionally they press a button which saves a milestone copy of their directory tree. They can optionally give milestones names. With another button, they can send their milestones to a server in the cloud. They can also browse the cloud looking for other people's milestones and fetch those. They can see the diffs between two milestones. And there probably needs to be a tool to help merge a set of changes into a directory, which can then be saved as yet another milestone.
Think: "what would Git look like if Apple designed it?" The result is probably not a tool that a hacker would use directly. But I would hand it to all my non-hacker colleagues in the hope of capturing their work in a repo which I could then pull, sort out, and merge into the main tree. And it would let them browse the history and pull stuff out of it without having to bother someone like me.
But I think I understand where you're coming from. My take is that all of these supposedly-simpler interfaces are nowhere near radical enough. If you try to make git easier by deleting half the feature set you end up with Emasculated Git. It's still obviously git, but it isn't git, so (e.g.) you ask your friend how to use git and they tell you ten things, half of which you can't do because the tool doesn't support them. Or you consult a git book and it seems both familiar and unfamiliar.
What I wish someone would try is designing a tool that has, say, 5% of Git's features, and a different name, but uses Git's protocols to interact with Git repos. The user presses a button to download a project from a URL. They tinker. Occasionally they press a button which saves a milestone copy of their directory tree. They can optionally give milestones names. With another button, they can send their milestones to a server in the cloud. They can also browse the cloud looking for other people's milestones and fetch those. They can see the diffs between two milestones. And there probably needs to be a tool to help merge a set of changes into a directory, which can then be saved as yet another milestone.
Think: "what would Git look like if Apple designed it?" The result is probably not a tool that a hacker would use directly. But I would hand it to all my non-hacker colleagues in the hope of capturing their work in a repo which I could then pull, sort out, and merge into the main tree. And it would let them browse the history and pull stuff out of it without having to bother someone like me.
In the Git community they call this an "alternative porcelain".
For subversion, changesapp or cornerstone might appeal to you.
DVCS has high intrinsic complexity, though i agree that simplifying assumptions could reduce git's apparent complexity
For subversion, changesapp or cornerstone might appeal to you.
DVCS has high intrinsic complexity, though i agree that simplifying assumptions could reduce git's apparent complexity
I find that committing parts of a file in GitX is much easier than using interactive mode in the terminal. That's not a question of understanding the git model, it's just choosing the best tool for the job.
I completely agree. For many tasks the command line sequence of add, commit, push may be sufficient, but sometimes I don't care to wade through my editor merging and selecting portions of diffs to commit. The GitX interface is much more usable in that instance.
If you want to learn git, open a terminal and read the man pages, create a dummy repository, push changes to it, pull from it, clone it, merge it, etc. Don't start with something like Gitbox because its hides all the details and more importantly the beauty and elegance of git.
I think that's the point of the project - to hide the details. I'm a developer of project X, but a user of git. I don't care about it - I want to see it as little as possible, because it's just another tool. Whether it's beautiful or not, I've got a work to do.
It's a bit like with the compiler: it can be pretty and all, but ultimately I just want to write `make` and get my binary. When I need the details, I know where to find them.
It's a bit like with the compiler: it can be pretty and all, but ultimately I just want to write `make` and get my binary. When I need the details, I know where to find them.
I would argue that your SCM tool should be less like a compiler that just needs to get out of your way and just do it's job how you expect it and more like a text editor. Do you use emacs or vim, which have learning curves but are powerful and help you ultimately do your job much better and more efficiently? Or do you use Notepad, which just edits text and who cares? I think most developers prefer Emacs or Vim or even an IDE. You invest time in a more complex tool so that you can be a better developer.
That being said, I think this will be useful for a lot of less-techy designers or copy-editors or QA people, etc. People who can just open stuff in Notepad because they don't need to craft code.
That being said, I think this will be useful for a lot of less-techy designers or copy-editors or QA people, etc. People who can just open stuff in Notepad because they don't need to craft code.
I think the argument here is that
a) basic Git isn't that complex b) Learning a dumbed down subset of Git won't help you long term
I would say that giving people a gentle introduction to stuff is great, but it's important to make sure that it is a launch-pad for really learning the tool properly in the future.
a) basic Git isn't that complex b) Learning a dumbed down subset of Git won't help you long term
I would say that giving people a gentle introduction to stuff is great, but it's important to make sure that it is a launch-pad for really learning the tool properly in the future.
I can see this being useful where you have lots of developers, most of whom simply need to get stuff done and don't particularly care about the beauty of git. You have your local git expert who can do the hard stuff and fix all the problems, and everybody else uses gitbox.
Don't get me wrong Gitbox (and similar 'pretty wrappers') have their place just not as a learning tool.
My rule of thumb for 'mission critical software' like version control systems - if you can't access its fully functionality at the shell when logged in to a remote machine then forget about it.
Gitbox is great for your workflow until the day you have to actually use git and you have no time to 'actually' learn git.
My rule of thumb for 'mission critical software' like version control systems - if you can't access its fully functionality at the shell when logged in to a remote machine then forget about it.
Gitbox is great for your workflow until the day you have to actually use git and you have no time to 'actually' learn git.
Yes, the point of Gitbox is to hide the details but that's not necessarily a bad thing.
I've had to teach plenty of people how to properly merge files using Git and no one has ever said "oh that makes sense". If a tool can hide the ugliness of merging conflicting files, even a little, it'll help a ton of people get used to using Git.
I've had to teach plenty of people how to properly merge files using Git and no one has ever said "oh that makes sense". If a tool can hide the ugliness of merging conflicting files, even a little, it'll help a ton of people get used to using Git.
So rather than a tool which shows a diagram of my project with all the branches I've made, you'd rather I read a book with a diagram of someone else's project with all the changes they made?
Interfaces are interfaces. CLIs are good for some things, but bad at discoverability and limited in their communication.
Interfaces are interfaces. CLIs are good for some things, but bad at discoverability and limited in their communication.
Another vote or Pro Git - great book. And the last chapter where the author steps you through manually inserting objects into the git database is revelatory.
not everyone needs to understand how git works. In a couple of projects I work on, for instance, there are webdesigners who NEVER touch code and never used any sort of VCS before (and no, they DO NOT need to learn it) - making it simpler for them to use git is a big win for everyone in the project :-)
just an addon, #git channel on irc.freenode.net are skilled and very helpfull.
This looks pretty ok but I have to say it again: Gitx is awesome. I use this every day.
http://gitx.frim.nl/seeit.html
You can also try out the experimental fork version:
http://wiki.github.com/brotherbard/gitx/
http://gitx.frim.nl/seeit.html
You can also try out the experimental fork version:
http://wiki.github.com/brotherbard/gitx/
They're going to need to do a lot more UI work before I'd even consider this over GitX. Right now it looks like a less useful, less pretty, more confusing version of GitX.
God I wish I understood GIT. The screenshot here doesn't help me in any way. Tempted to stick with gitx. What is the advantage of this software?
Sign up for a github account. It's free and they have help. If you're on Windows, I've been told TortoiseGit is good.
http://code.google.com/p/tortoisegit/
http://code.google.com/p/tortoisegit/
I like github too. It's very understandable - I find it better than the app shown here - and the help is great.
I'm with you, and I do understand Git fairly well. The UI is pretty opaque for non-VCS/Git users.
at first glance, I prefer GitX, as it allows faster and more fine-grained staging and commit.
the only feature this seems to have over GitX is push/pull.
my typical usage is GitX for commits and history browsing and the shell for everything else.
the only feature this seems to have over GitX is push/pull.
my typical usage is GitX for commits and history browsing and the shell for everything else.
+1
And I highly encourage everyone to get familiar with the command line first.
I'm still divided how I feel about these things. On the one hand, I actually find them very useful for staging and unstaging changes and visualizing branch/merge history, but on the other I worry for the people whose only interaction with git is via one of these GUI wrappers. To my mind, they keep you "too far away" from the gears of the version control system, and in this case a distributed version control system — a very important point to remember, as people who only use this and never a command line wouldn't have a hope in hell of using the distributed part of git — rebase a branch? merge in several heads? I'd like to see them try.
As for this particular one, though, I can't see it offers any advantage over GitX, apart from the "it's not a RubyCocoa app", which isn't really that great an advantage to my mind…
As for this particular one, though, I can't see it offers any advantage over GitX, apart from the "it's not a RubyCocoa app", which isn't really that great an advantage to my mind…
It seems to me that a lot of popular Unix-originated software seems to have really high learning curves (Vim comes to mind).
I wish projects like git spent more efforts on things like GUIs.
Does anybody know of any Linux alternatives?
I wish projects like git spent more efforts on things like GUIs.
Does anybody know of any Linux alternatives?
My feeling is that people's strong preference for one interface and stern rejection to the other (GUI vs. CLI) are sometimes more psychological than technical.
The truth, I think, lies somewhere in the middle. CLI and GUI are essentially complementary modes of interacting with the computer. CLI is generally easier if you can remember the commands and the options, which is the case if you use them a lot. If you don't use certain functions a lot, a nice GUI (like Gitbox) can help you find them quickly. Of course whenever you have to repeat a command many times you should automate the process by writing a script, but in theory you could link that script to a button or menu item in a GUI. It doesn't have to stay at the command line.
The truth, I think, lies somewhere in the middle. CLI and GUI are essentially complementary modes of interacting with the computer. CLI is generally easier if you can remember the commands and the options, which is the case if you use them a lot. If you don't use certain functions a lot, a nice GUI (like Gitbox) can help you find them quickly. Of course whenever you have to repeat a command many times you should automate the process by writing a script, but in theory you could link that script to a button or menu item in a GUI. It doesn't have to stay at the command line.
Apple's A/UX had a nifty interface feature: but if you double-clicked a UNIX command-line executable and a `Commando script' existed for that program, then a little window would pop up with the common options. It would show you the command line that it was putting together, and when you click OK, it would bring up a terminal and run the command in it.
Here's a screenshot of how it worked for ls(1): http://applefritter.com/ui/aux/images/cmdo-ls.gif
Here's a screenshot of how it worked for ls(1): http://applefritter.com/ui/aux/images/cmdo-ls.gif
Then again, git is not a consumer software. Developer should spend some time and learn 5 commands to be productive.
But I find this interface interesting, even knowing all command line git this makes browsing history for reviews easy, nice tool.
But I find this interface interesting, even knowing all command line git this makes browsing history for reviews easy, nice tool.
The command line is very efficient for input of commands, far more so than GUIs (though keyboard shortcuts mitigate this). GUIs are far more efficient for output of infomation though, especially verbose info like history, log files, etc. It surprises me that die-hard CLIers often fail to recognise this.
And, in fact, my git setup has evolved to rely on magit (an emacs-based git GUI of sorts) for some operations, and the command line for others, and GitX for others.
In this case the best tool, even for experts, is a hybrid tool.
In this case the best tool, even for experts, is a hybrid tool.
>> a lot of popular Unix-originated software seems to have really high learning curves
>git is not a consumer software
I don't understand. What does being consumer software or not have to do with learning curves? Do you think developers don't appreciate simplicity or discoverability?
>git is not a consumer software
I don't understand. What does being consumer software or not have to do with learning curves? Do you think developers don't appreciate simplicity or discoverability?
The more time is spent learning something, the better you can use it later. For consumer software, getting stuff done right now without any prior education is important. For developer tools, learning your tools is a necessity to perform the task better.
If you hide complexity behind a pretty UI, you end up with broken projects when something unexpected happens during push to production and nobody on your team spent time reading the manuals. So what I'm saying, I guess, is that steep learning curve for real tools is a good practice which should not be avoided. You don't want to be operating a chainsaw without reading the manual first.
If you hide complexity behind a pretty UI, you end up with broken projects when something unexpected happens during push to production and nobody on your team spent time reading the manuals. So what I'm saying, I guess, is that steep learning curve for real tools is a good practice which should not be avoided. You don't want to be operating a chainsaw without reading the manual first.
Why do you think a command line interface helps learning more than a GUI one?
In your own language, isn't a CLI simply hiding an API in much the same way a GUI one is?
I used to teach people Linux Volume Management. Far more people understood what they were doing with a visual aid - either in, or outside the app - than those who ran the commands without any context to what was actually happening.
In your own language, isn't a CLI simply hiding an API in much the same way a GUI one is?
I used to teach people Linux Volume Management. Far more people understood what they were doing with a visual aid - either in, or outside the app - than those who ran the commands without any context to what was actually happening.
"Say, you move a file from one folder to another: in the Terminal you would have to “git rm” the old path (the file is gone, so no tab-completion) and “git add” the new path" -- from the homapage. well "git mv" is doing that just fine...
It doesnt appear to serious on the homepage of a git product :)
http://www.kernel.org/pub/software/scm/git/docs/git-mv.html
It doesnt appear to serious on the homepage of a git product :)
http://www.kernel.org/pub/software/scm/git/docs/git-mv.html
That aside, "git rm" (and "svn rm" and "cvs remove" for that matter) all tab-complete for me even when the "file is gone".
If you're a developer:
Git is faster to work with and more powerful to use from the command line if you take maybe 20 minutes to go through a good tutorial. It took you much longer to learn how to program, and it's worth taking the time to get good at it.
If you're a designer, writer, etc: Even though it only takes 20 minutes to learn, if a GUI is what it takes to get you to use version control I guess that is the lesser of two evils :)
If you're a designer, writer, etc: Even though it only takes 20 minutes to learn, if a GUI is what it takes to get you to use version control I guess that is the lesser of two evils :)
That's not true. You can't learn git in 20 minutes or 2 hours, unless you equate learning git to learning to type simple commands like 'git pull' and related. But then you're not really learning git, you're just typing generic VCS commands.
You can read about the basic architecture and concepts of git in 2 hours. It's not that complicated.
You may need more than those 2 hours to really digest and understand everything, and see how it plays out in practise. But after the first 2 hours you should be ready to use git. (Actually you should be using git, because how else are you going to learn?)
You may need more than those 2 hours to really digest and understand everything, and see how it plays out in practise. But after the first 2 hours you should be ready to use git. (Actually you should be using git, because how else are you going to learn?)
I love the cheat gem.
sudo gem install cheat
Then do :
cheat git
A great shortcut to all of the common git command sequences.
sudo gem install cheat
Then do :
cheat git
A great shortcut to all of the common git command sequences.
sweet didn't know about it, it's very handy with my little Mac OS X alias to open preview from command line :
alias preview='groff -Tps > /tmp/tmp.ps && open -a Preview /tmp/tmp.ps'
So you can do :
cheat git | preview
alias preview='groff -Tps > /tmp/tmp.ps && open -a Preview /tmp/tmp.ps'
So you can do :
cheat git | preview
Nice, very cool alias. Thank-you!
P.S. As an added note, there are TONS of cheat sheets out there. Just do a 'cheat sheets' from the command line and you'll get the all listed. Some of the more common ones I would suspect in the HN community are :
cheat svn
cheat rails
cheat named_scope
cheat curl
cheat blueprint
cheat bash
cheat mysql
cheat ruby
P.S. As an added note, there are TONS of cheat sheets out there. Just do a 'cheat sheets' from the command line and you'll get the all listed. Some of the more common ones I would suspect in the HN community are :
cheat svn
cheat rails
cheat named_scope
cheat curl
cheat blueprint
cheat bash
cheat mysql
cheat ruby
Awesome, thanks for sharing that alias.
And an excellent read to learn about Git is http://tom.preston-werner.com/2009/05/19/the-git-parable.htm..., from a GitHub cofounder.
There needs to be a "for human beings" version of everything, because, we are all, human beings!
human after all
The git that everyone would use is to the actual git what the app store is to apt-get. ;-)
If that's the only way that you'll use version control, it's better than nothing. On the other hand, I heartily endorse actually learning how the git model works -- it's not too bad, I promise!
.
Good places to start:
[1] http://peepcode.com/products/git-internals-pdf
[2] http://book.git-scm.com/
[3] http://progit.org/book/