1. Never tell me what to do. How about "Why I don't.." instead. I'm not sure why you are qualified to give me an absolutism in the first place considering you've only been a professional developer for 5 years. Now get off my damn lawn.
Most times when someone on my team screws up a commit, it's because they botched the command line (the inverse of this article's claims). Fix it in Tower in a few minutes in a visually simple way that helps them understand what's going on.
It also makes submodule usage do what you think it should do.
Agreed. This article is stupid because it extrapolates from a few cases he's seen personally (and it was his coworkers messing up; I'm sure he's such a good developer that he's never made a mistake attributable to the command line tool, like making a typo).
And as long as we're being totally unscientific about the whole thing, the most common mistake I've seen when using a version control system has come from people checking in unintentional modifications using the command line tool because it is easy to miss. In a GUI, you can better see what is being committed, and a simple checkbox lets you skip it, while double clicking gives you a diff that makes it so much easier to review every change before you commmit.
There are things I can do in http://git-cola.github.com/ that I simply can't do on the command-line. That's why I use a GUI.
To be fair, I wrote it, so I know exactly what commands it runs. I do think I've done a decent job of making it very clear what's going on under the hood, though. I even have a mode where the tool prints every git command it runs.
In general, though, I agree that folks should have an understanding of the underlying concepts. That way the GUI becomes a supplementary tool (rather than a crutch). This advice is not limited to just GUIs, though.
agreed, git-cola is way more usable than the git command line for breaking your uncommitted changes into a series of partial commits. that's the one time i will absolutely use a gui tool as being the best tool for the job.
There are really really great Git GUIs out there. Tower is the one example everyone is citing. That said, Tower is a largely transparent wrapper around the git command line. Pretty much every button corresponds to one and only one command in the terminal. All it really does is to give you visual feedback and meta-information on what you are doing.
This works really well. You have to understand Git in order to use it efficiently, but once you do it is in many cases just a more convenient way of using Git.
Well, and then it knows to do a `stash/pull --rebase/stash pop` instead of a simple pull if you want to.
On the very other end of the spectrum is Github for Windows, which literally only has one button "Sync" for all that is pull, push, fetch, rebase etc. It is a giant PITA. Also, it does have an interactive commit view with files and checkboxes BUT IT DOES NOT STAGE STUFF WHEN YOU CHECK THE BOXES. This drives me nuts! Also, it trips up and dies if you stage stuff externally. I die a little every time that app breaks something.
Thus, I don't have anything against VC GUIs at all as long as they stay true to the command line. But any kind of abstraction is bound to leak at some point. This might be OK in some places, but your VC is not the right place to store leaked Git abstractions.
In many other places though, command line abstractions work just fine. Maybe this is more a comment about Git being hard to abstract than an argument against abstracting command line tools in general. And maybe that does not say anything good about Git.
One thing that I've noted about the git integration in XCode4 -- the thing seems to put me on a branch to commit and take me off of it right after. If one isn't aware of this happening, bad things can result from an ill-timed command line git command.
Is this fear common amongst developers? My startup http://gitpilot.com is trying to make collaboration amongst developers using Git stupidly simple. A by-product of doing this is a simplified Git process. However, maybe our approach is off. Any opinions on the matter?
It looks like just another github equivalent, and I spied a Mac dock so is it Mac specific too?
In any event what I have found missing is a goal oriented interface. To many of the guis and the git cli are all about tasks. If you know what tasks map to your goals then it works out ok, but if not (as is the case for perpetual intermediates) then it is a confusing maze of bizarre commands, useless messages and copy/paste from google search results hoping one of them will work. For context see this http://www.drdobbs.com/goal-directed-software-design/1844099...
Git also has all of its defaults setup for large groups. For example tags are not pushed unless you specify an additional flag. That is absolutely the right thing to do when there are lots of developers, but the "wrong" thing when there are only two.
Nirvana for me would be a gui tool (Linux and Mac) that interoperates with projects hosted at Github and has a goal oriented interface. It should be smart about things (eg tags not being pushed in a project of two people is worthy of attention), and it should enable a git workflow (eg topic branch, pull requests, reviews etc). I really don't care what the git commands are to do various things - there are often several needed in some particular order with various random flags. Just help me and other perpetual intermediates reach our goals and concentrate on our development efforts, not micromanaging a version control system.
Part of that also means having an attitude about the right way/best practise way of doing something. Rather than providing endless configurable ways (and dialog boxes) to do something, pick one right way even if not everyone would agree. An example would be to always push tags for projects with few developers.
Thanks for taking the time to provide some feedback. The article that you presented was really interesting and despite being over 15 years old, it seems that its insights are still valid today.
Regarding Gitpilot, I think that our biggest problem at the moment is that maybe we are miscommunicating its value proposition. As it's a compliment to Github and not a replacement. I think you'd also find that it's at least attempting to be goal oriented as opposed to being task oriented like most Git GUIs. For the sake of brevity, Gitpilot is best described as a git-flow GUI [http://nvie.com/posts/a-successful-git-branching-model/, https://github.com/nvie/gitflow/]. (Our branching model is a bit different though)
It is Mac specific at the moment and it's currently awaiting review for the Mac App store. If you're interested, when it's live, I'll send you and your team promo codes so that you can try it out at no cost. If so, send me an email to jp [AT] gitpilot.com
Alan Cooper (article author) also has a company and wrote several books (About Face, Inmates etc). And is considered the father of Visual Basic! But yeah, goals are timeless. I wish software/website authors realised that the goal of most users is to use their software and site for as little time as possible because they manage to achieve their goals quickly. Dialog boxes and similar stuff annoy the crap out of me. The programmer of the app/site has deep comprehensive information and they can't make their mind up, then why dump it on the user? You can trivially mitigate most things. For example if you provide undo across sessions then you don't need to ask users if they really meant to delete. Firefox on Android does a great thing - any closed tabs are shown at the bottom for a short period of time somewhat faded. Touch it to bring it back to life.
We have 4 git users on the team. The one writing the most code (me) is Linux only. The next person (about half time git) is almost entirely Mac. Another two use git but have no idea what it does and do not care (both Mac). They merely run the tools we store in git. Additionally our stuff is scattered across several repositories (for good reason). To do work you need one more of them. The Github for Mac client only lets you sync one repository at a time which is painful. I wrote a script in the end that syncs all repositories.
I would love to have a goal oriented gui for a git flow since I'm very lax at the moment, not having time to learn how to micromanage the sequence of commands needed. Heck I still have to look up the flags to git stash everything time I use it.
But being Mac only means your software is of no value to us. Thanks for the offer though.
TortoiseHg is fantastic for Mercurial, but there are no comparable Git GUIs that I know of. Github for Windows looks nice, but it tends to be slightly unstable.
In my experience, open source GUIs for open tools generally have that unpolished "design by committee" feel of a Diablo 1 inventory hacker written in Visual Basic, so I can relate to the hate a little bit.
> I claim that any GUI which sufficiently exposes the underlying tool’s features to know with confidence what clicking any button will do fails at being any more intuitive than the command line tool itself;
I think this is the meat of the article here. Other commenters have noted that Tower more or less falls into this category, i.e. a mostly 1-to-1 mapping of GUI elements onto git commands, and you need to know git to use Tower. I would add Magit to this category as well. You could not use either one unless you already understand git itself and how to use it.
However, I don't think that these GUIs are useless simply because they are not more intuitive than the command line. While they may not abstract any of the intrinsic complexity of git, they certainly make git much easier to use simply by taking away a lot of the techincal complexity in day-to-day usage.
Actually, source control GUIs are excellent for less-technical team members. I've had great results using TortoiseSVN or the GitHub client with multiple distributed teams.
It's great to be able to tell a new team member: "Press this button to get everyone else's updates." "Press this button to push your updates to the server/current branch." Later, depending on their role and level of skill, we can cover branching, merging, tagging and other move advanced features.
My experience has been that developers using a gui make better commits. It is far easier to see what the changes are, see unintended code changes, make a more useful message and only pick a relevant subset of changed hunks.
The command line only folks tend to do 'git commit -a' or equivalent and have messy noisy commits.
Yes a highly skilled developer at the top of their game, paying attention to every detail and pumped full of caffeine is far less likely to do that, but they are rare.
"I claim that any GUI which sufficiently exposes the underlying tool’s features to know with confidence what clicking any button will do fails at being any more intuitive than the command line"
Based on that claim, he should also be opposed to word processors, visual text differs, and vi. After all, all they expose are the features of troff+Ghostscript, diff, and the combination of ed and sh.
21 comments
[ 2.9 ms ] story [ 42.5 ms ] thread2. And you've apparently never used Tower.
Most times when someone on my team screws up a commit, it's because they botched the command line (the inverse of this article's claims). Fix it in Tower in a few minutes in a visually simple way that helps them understand what's going on.
It also makes submodule usage do what you think it should do.
And as long as we're being totally unscientific about the whole thing, the most common mistake I've seen when using a version control system has come from people checking in unintentional modifications using the command line tool because it is easy to miss. In a GUI, you can better see what is being committed, and a simple checkbox lets you skip it, while double clicking gives you a diff that makes it so much easier to review every change before you commmit.
There are things I can do in http://git-cola.github.com/ that I simply can't do on the command-line. That's why I use a GUI.
To be fair, I wrote it, so I know exactly what commands it runs. I do think I've done a decent job of making it very clear what's going on under the hood, though. I even have a mode where the tool prints every git command it runs.
In general, though, I agree that folks should have an understanding of the underlying concepts. That way the GUI becomes a supplementary tool (rather than a crutch). This advice is not limited to just GUIs, though.
This works really well. You have to understand Git in order to use it efficiently, but once you do it is in many cases just a more convenient way of using Git. Well, and then it knows to do a `stash/pull --rebase/stash pop` instead of a simple pull if you want to.
On the very other end of the spectrum is Github for Windows, which literally only has one button "Sync" for all that is pull, push, fetch, rebase etc. It is a giant PITA. Also, it does have an interactive commit view with files and checkboxes BUT IT DOES NOT STAGE STUFF WHEN YOU CHECK THE BOXES. This drives me nuts! Also, it trips up and dies if you stage stuff externally. I die a little every time that app breaks something.
Thus, I don't have anything against VC GUIs at all as long as they stay true to the command line. But any kind of abstraction is bound to leak at some point. This might be OK in some places, but your VC is not the right place to store leaked Git abstractions.
In many other places though, command line abstractions work just fine. Maybe this is more a comment about Git being hard to abstract than an argument against abstracting command line tools in general. And maybe that does not say anything good about Git.
In any event what I have found missing is a goal oriented interface. To many of the guis and the git cli are all about tasks. If you know what tasks map to your goals then it works out ok, but if not (as is the case for perpetual intermediates) then it is a confusing maze of bizarre commands, useless messages and copy/paste from google search results hoping one of them will work. For context see this http://www.drdobbs.com/goal-directed-software-design/1844099...
Git also has all of its defaults setup for large groups. For example tags are not pushed unless you specify an additional flag. That is absolutely the right thing to do when there are lots of developers, but the "wrong" thing when there are only two.
Nirvana for me would be a gui tool (Linux and Mac) that interoperates with projects hosted at Github and has a goal oriented interface. It should be smart about things (eg tags not being pushed in a project of two people is worthy of attention), and it should enable a git workflow (eg topic branch, pull requests, reviews etc). I really don't care what the git commands are to do various things - there are often several needed in some particular order with various random flags. Just help me and other perpetual intermediates reach our goals and concentrate on our development efforts, not micromanaging a version control system.
Part of that also means having an attitude about the right way/best practise way of doing something. Rather than providing endless configurable ways (and dialog boxes) to do something, pick one right way even if not everyone would agree. An example would be to always push tags for projects with few developers.
Regarding Gitpilot, I think that our biggest problem at the moment is that maybe we are miscommunicating its value proposition. As it's a compliment to Github and not a replacement. I think you'd also find that it's at least attempting to be goal oriented as opposed to being task oriented like most Git GUIs. For the sake of brevity, Gitpilot is best described as a git-flow GUI [http://nvie.com/posts/a-successful-git-branching-model/, https://github.com/nvie/gitflow/]. (Our branching model is a bit different though)
It is Mac specific at the moment and it's currently awaiting review for the Mac App store. If you're interested, when it's live, I'll send you and your team promo codes so that you can try it out at no cost. If so, send me an email to jp [AT] gitpilot.com
Thanks again.
We have 4 git users on the team. The one writing the most code (me) is Linux only. The next person (about half time git) is almost entirely Mac. Another two use git but have no idea what it does and do not care (both Mac). They merely run the tools we store in git. Additionally our stuff is scattered across several repositories (for good reason). To do work you need one more of them. The Github for Mac client only lets you sync one repository at a time which is painful. I wrote a script in the end that syncs all repositories.
I would love to have a goal oriented gui for a git flow since I'm very lax at the moment, not having time to learn how to micromanage the sequence of commands needed. Heck I still have to look up the flags to git stash everything time I use it.
But being Mac only means your software is of no value to us. Thanks for the offer though.
In my experience, open source GUIs for open tools generally have that unpolished "design by committee" feel of a Diablo 1 inventory hacker written in Visual Basic, so I can relate to the hate a little bit.
I think this is the meat of the article here. Other commenters have noted that Tower more or less falls into this category, i.e. a mostly 1-to-1 mapping of GUI elements onto git commands, and you need to know git to use Tower. I would add Magit to this category as well. You could not use either one unless you already understand git itself and how to use it.
However, I don't think that these GUIs are useless simply because they are not more intuitive than the command line. While they may not abstract any of the intrinsic complexity of git, they certainly make git much easier to use simply by taking away a lot of the techincal complexity in day-to-day usage.
It's great to be able to tell a new team member: "Press this button to get everyone else's updates." "Press this button to push your updates to the server/current branch." Later, depending on their role and level of skill, we can cover branching, merging, tagging and other move advanced features.
The command line only folks tend to do 'git commit -a' or equivalent and have messy noisy commits.
Yes a highly skilled developer at the top of their game, paying attention to every detail and pumped full of caffeine is far less likely to do that, but they are rare.
Based on that claim, he should also be opposed to word processors, visual text differs, and vi. After all, all they expose are the features of troff+Ghostscript, diff, and the combination of ed and sh.