Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In my company I am faced with assertion that graphic interfaces for VCSs like SVN or (especially) Git tend to mess repositories - especially regarding branching.

Being a passionate Windows and GUI user, I have a hard time believing this is true.

For Git especially, I accept that some moves are too complex for conduction via a GUI. But what is the real background of this accusation?

share|improve this question
    
LOL very good assertion. And the 1st april is still far away. –  BЈовић Mar 19 '12 at 10:57
    
Hopefully my edit makes this question a little less like close-bait. I do think there is a genuine prejudice against GUI tools, and I think it is worth understanding why (other than snobbery) so that we can understand when GUI tools are appropriate and when the command line is a better option. –  Mark Booth Mar 19 '12 at 11:16
5  
It really depends on the GUI. First time users find TortoiseGit very confusing and would basically brute-force their way to getting something checked-in, which means that they might or might not mess up the repository. In a hackathon I participated a few months first time users were able to break the repository (fast forwards, bad merges, etc) on several occasions. They weren't able to get a good overview of what's going on. git-gui and especially SmartGit were much much easier to comprehend and work with (git-gui however being very limited in functionality). –  Ivan Zlatev Mar 19 '12 at 11:51
    
Done - it's now an answer. –  Ivan Zlatev Mar 19 '12 at 14:03
    
-1? for what reason? –  Raffael Mar 19 '12 at 14:14
add comment

5 Answers 5

In my experience, a well designed GUI front end, like TortoiseHG doesn't in itself cause problems, what does cause problems however are user misunderstandings and inattentiveness.

I use thg as an example because my exposure to TortoiseSVN and TortoiseGit is limited.

With a GUI tool, it is very easy for an inexperienced user not to notice that the tool is going to do something they don't expect. For instance, with Mercurial, you can have an arbitrary number of unnamed remote heads. Normally Hg will complain if you try to push an unnamed remote head, but if you have the 'force push' option checked in the GUI, it won't complain and just push up the head anyway. This can result in confusion as people wonder what is this branch for, is it stable and should I be using it?.

With a command line tool, such situations will result in an error or warning being displayed and the users will need to understand the error in order to work out how to either correct the error (merge in the branch that is causing the error) or ignore it (rename the branch so it's purpose is obvious and then force the push if it shouldn't be merged right now).

Ultimately, while GUI tools make it easier to get started with a VCS, they are not a substitute for understanding how the VCS actually works. This is why many people recommend learning the command line first and then migrating certain tasks to GUI tools later to optimise your workflow.

share|improve this answer
add comment

It really depends on the GUI. First time users find TortoiseGit very confusing and would basically brute-force their way to getting something checked-in, which means that they might or might not mess up the repository. In a hackathon I participated in a few months ago first time users were able to break the repository (fast forwards, bad merges, etc) on several occasions. They weren't able to get a good overview of what's going on. git-gui and especially SmartGit were much much easier to comprehend and work with (git-gui however being very limited in functionality).

(Moved to be an answer as per the comments to my comment).

share|improve this answer
    
Thanks Ivan, I think your answer complements my answer well. My experience with git GUIs is very limited, as I always use the command line for git, hence my answer being from more of an hg perspective. –  Mark Booth Mar 19 '12 at 16:14
    
Agreed. I use cola (staging/committing) and gitk (history viewing/modification) in *nix and would hate life without them. That's part of the reason I don't like using git in Windows. The available tools still suck. –  Evan Plaice Mar 20 '12 at 22:42
add comment

I always though that GUIs encourage people to "just give it a spin" without reading the manual.

Operating svn/git without reading the manual is very akin to operate a machine gun without proper shooting range practice: collateral damages may will ensue.

There's also a problem with vcs savvy people using the command line, wanting nothing to do with the GUI, (Tortoise is so... click-menu-scroll-click-menu-scroll) and thus not helping the vcs gospel spread among the newcomers.

Then there could be an issue with new or external developers working on different platforms (those dang mac people doing iOS apps, or web developing/designing) using a different GUI from the one you use and needing some serious steady fast training that proves harder to impart than originally though.

share|improve this answer
    
I'm not familiar with polygon training. Could you explain please? –  user16764 Mar 20 '12 at 2:58
1  
It's interesting that there was a point where TortoiseHg switched from advanced features (mainly history editing features like rebase and strip) being enabled by default to them being diabled. I thought it a silly decision at the time, but as as time went on, I realised that it did encourage people to just give hg a go and meant that most of what they could do was relatively safe. I think this is now why we have a perception that hg is easier to use than git, the developers have made significant efforts to make it easier to use. –  Mark Booth Mar 20 '12 at 10:51
    
@user16764 I meant to write "shooting range". My hovercraft is full of eels. –  ZJR Mar 20 '12 at 13:37
    
It would help if the git manpage didn't suck in the traditional *nix fashion. It's written as a software users (ie developer) manual not as an end user's manual. There are side-projects that make it slightly easier for beginners but the program's design itself is just crap from a usability standpoint. It's impossible to learn it (gui or non-gui) without making mistakes because it requires the user to think like Linus did when he wrote it. It's painfully obvious that he didn't write it for anybody but himself. –  Evan Plaice Mar 20 '12 at 22:58
    
(cont) Mercurial goes a long way to make a DVCS 'for humans' but there's no switch to turn on the really powerful features like history re-writing. Git is powerful but anybody who claims it is fun to learn (gui or not) is either a liar or a masochist. –  Evan Plaice Mar 20 '12 at 23:29
show 1 more comment

Ignorance. Since that answer is too short, TortoiseSVN and TortoiseGit served me well until I saw the light and started using the shell, but that doesn't mean either tool is simple to use. If you don't understand the underlying functionality, the leaky abstractions and information hiding that is necessary to make a GUI which is more user friendly than the shell equivalent makes it really difficult to understand what is really going on below.

share|improve this answer
    
Any comment on the downvotes? I don't see how this answer is so different from @MarkBooth's (although his is better). –  l0b0 Mar 20 '12 at 9:43
    
I think it's because the other answers here go into a little more detail. Having said that, your edit yesterday made your answer much better. Also, remember that not everything is quicker on the command line. An example off the top of my head are the hunk selection facilities in TortoiseHg, which allow you to easily select only some of the changes within a file to be committed. This is much more cumbersome on the command line, and certainly easier to handle than git's index/cache/staging area. –  Mark Booth Mar 20 '12 at 16:30
    
@MarkBooth: It wasn't intended as a bash of GUI tools (although I can see how it could be read as such), but rather to say that understanding the shell tools improves understanding of the GUI tools a lot. I used Tortoise* for about four years, and have used mostly shell tools the last four years (with the notable exception of git gui for convenience over git add -i), and shell tools are much more transparent and efficient once you take the time to learn how they work. –  l0b0 Mar 20 '12 at 16:41
    
some people seem to be very eager for the critics badge ... +1 –  Raffael Mar 21 '12 at 8:45
add comment

Each and every (with small size of assertions) GUI implement two paradigms from triad "Nice - Smart - Fast". In most cases loser is Smart. The more complex the original system loses more in GUI boundaries and metaphors. Manual for Git is a must, thus - in the Procrustean bed of GUI it lost most part of functionality, compared to other VCS.

Another side is users. Because GUIs (see above) give impression of fast start and easy usage and hide some amount of information from end-user some noobs see no need to study, RTFM and STWF: "because it works even now!" unless "SHIT HAPPENS! Oh, it's a bad program" tells lazy, stupid, illiterate and noisy "monkey with grenade" (see at most git-boys here, on SE - no RTFM, no local search)

Assertion is right from the side "GUI mess..."; and is wrong from another side: in determining the cause and effect relations and subject-object nature.

Statistically and logically not GUI, but users of... tend to mess, as they tend to mess any complex task in any area

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.