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?
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.
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).
git GUIs is very limited, as I always use the command line for git, hence my answer being from more of an hg perspective.
Mar 19, 2012 at 16:14
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.
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.
Mar 20, 2012 at 10:51
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.
git's index/cache/staging area.
Mar 20, 2012 at 16:30
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.
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
