Git is a version control system used for software. Git does have some advantages over it's predecessors but none of them are related to making anything easy. After wasting anywhere from several minutes per day up to several hours per day over many months, Git has not produced a single successful test.
The simplest test of version control is to save a file then restore it. Git failed 48 times out of 50. Git failed every time there was more than one file. Some of the files returned by git had absolutely no relevance to anything saved in Git.
Read about version control in Bazaar or Git or Mercurial for version control?
Git runs on a server. You access Git using a client. The process is similar to using an email client. Email clients are well developed and easy to use. Git clients are mostly locked in the previous century and are about as inviting as a visit to the dentist.
Git versus predecessors
The first common version control on Linux was CVS and it was primitive compared to basic commercial version control software at that time.People built a million add-on scripts for CVS but CVS lacked basic design features and was slow.
SVN was a small step up for Web based projects because SVN had some publishing features that fitted in with Web sites. SVN was still slow and lacked controls.
Git added excellent processing for a distributed environment. Git still lacked controls for allocation of work to members of a team. You could simulate those controls by controlling who could merge into a given repository. Git works for open source because anyone can copy down from the repository. Git works for networks of developers because groups of developers can merge code up to a repository for their area then the next layer of management can merge from several areas.
Neither Git nor any of the predecessors allow for allocation of a code change to a specific developer with all other developers locked out of that code for the duration of the change project. The Git approach can end up with massive amounts of retesting because you do not know who contributed what or when. Typically you implement an issue management system and tie the changes to the issue management system issue records then use the issue management history to decode the mess made by several incompatible changes arriving at the same time.
Why use a graphical user interface?
The graphical user interface was invented in the 1950s for air defence systems because a 1970s Unix style command line is too slow when the enemy is flying in with nuclear bombs. Xerox Parc developed the first modern GUI for their Alto computers. The Alto interface was cloned by a bunch of companies including Tandy, DRI, Apple, Commodore, and Microsoft. Microsoft built their GUI to fit the available hardware and the first successful GUI based operating system was Windows 95 when affordable hardware could keep up. The Atari was the second most successful GUI based computer and most of that success was based on games. Apple released the Lisa as their principle GUI computer and it bombed because of Apple's impossible pricing. Apple then tried again with the Mac but the early Macs wasted so much time that the sales people selling Macs invented all sorts of fraudulent techniques to sell Macs. I unfortunately wasted an hour while the sales person tried to demonstrate what would take two minutes on my IBM PC.
The big turning point in GUIs occurred in the early 1990s when good graphical systems were reduced to a single chip. Considering the early SAGE systems cost $12 billion dollars for just a few machines, the 1990s GUI chips cost $10 per computer and Windows 95 capitalised on that low cost. Apple did no convert to the modern way until the next century when they copied everyone else and became the last computer company in the world to adopt the Intel/AMD platform. As Apple said at the time, the Intel/AMD platform was 2.45 times faster than the junk Apple were selling before.
The GUI interface has a whole lot of advantages. You can easily show a range of items with colour coding, icons, and highlighting to indicate their use. The user can then select the exact items required. The user then selects a single control to perform changes on all the selected items. Compare that with a command line interface where the user can only select based on patterns related to naming conventions that break the semantic approach and may not be consistent anyway, as demonstrated at a training course where the teacher was unable to complete this type of action on hist own computer due to some slight variations away from his artificially imposed naming conventions.
I am not saying the command line interface is impossible for all projects, just that it is impractical for modern projects with multiple people from different backgrounds trying to work together. A good GUI application overcomes all the limitations of a command line user interface.
Linux and Windows
This section is for programs that work the same on Linux and Windows so you can move between the two without having to learn to use a different tool. These programs might also work on other operating systems including normal Unix and OSX Unix.
SmartGit
SmartGit is one of the best Git clients but costs money and has all the disadvantages of commercial software. If SmartGit was free open source software with no licensing restrictions, it would be my first choice for use across multiple operating systems. unfortunately SmartGit version 2 does not work on Linux and the version 3 preview does not let you do some of the basics, including add files. Try SmartGit after they release 3.1.
To use SmartGit, I would have to buy a licence for every one of my computers, despite being able to use only one at a time, and the cost would be about $300 per year. The cost would be reasonable if I used the client professionally but I would use it only to donate the odd bit of software to free open source projects. SmartGit does run on most operating systems and could be the choice for a professional about to migrate from Windows to Linux or OSX to Windows.
An additional consideration is the cost when you bring other people into a project and give them the same tools. Would you pay $60 per person for a tool they will use for only a few minutes each day for a few days? I find it is better to start everyone using tools they can use long term.
EGit
EGit is part of the Eclipse project. If you use Eclipse and only Eclipse, use EGit. Eclipse is too big for many of my projects and I use a lot of other systems. EGit looks like it will only be of use inside Eclipse and have to use something else for other projects. Eclipse has a PHP add-on product but the combination is painful. After many attempts at using Eclipse for PHP, I give up. Eclipse requires Java, another reason to not use Eclipse.
Git-gui
Git-gui is supplied with Git but is impossible to use when installed by the default installation on Ubuntu Linux. On Ubuntu, Git-gui is not installed by default with Git. You have to select the GUI as an optional extra. Without the GUI option, Git is an unusable teletype application from back in the days before your grandmother learned to program. When you do remember to select the GUI option, the GUI does not appear on any menu and Git remains trapped in the early days of the previous century.
NetBeans
NetBeans is based on Java but the latest version, version 7, appears to be reliable. NetBeans has a Git interface. NetBeans has a PHP component and, for PHP development, the NetBeans PHP combination works better than the clunky Eclipse PHP combination. The NetBeans PHP download is only half the size of the Eclipse PHP download because NetBeans does not assume you want the Java junk. See the NetBeans download comparison at netbeans.org/downloads/index.html.
I am recording my experience in NetBeans. Netbeans gives Bluefish good competition on any computer fast enough to run Java applications but is still not fast enough to start for a quick edit. On a two year old computer with a fast processor and fast magnetic disks, NetBeans is noticeably slower than Bluefish for most things. My next computer, still on my assembly bench, will have a processor three times faster and SSD storage five times faster. The speed difference between Bluefish and NetBeans might be less important.
Linux
There are no Git clients worth using on Linux unless you are willing to page $60 per computer or happen to be already buried in Eclipse. OSX users have even less choice. Windows users have access to some nicer Git clients. Comparing Linux Git clients to the best free Windows Git client is embarrassing, especially for someone who has recommended Linux. Think about a person with a Samsung Galaxy S II smartphone standing next to someone with a tin can and some string. The person with the tin can is bragging about adding masking tape to the sharp edges of the tin can so the can will not cut your ear off. A Git client on Linux is sort of like the tin can fitted with the masking tape.
git-cola
git-cola is the choice for Python fans. For everyone else, it has a painful introduction. You are dropped onto a tiny option box with just three buttons and no information. I made some attempts to use it then deleted it.
Gitg
Gitg is closer to a normal application but has no documentation you can read before installing it. The help button just directs you to a Web page that says someone is thinking about creating a Web site one day.
Giggle
Giggle has a nice logo and users say it is nice for viewing Git but useless for making changes.
Windows
Tortoisegit
Tortoisegit would be the most common Git client on Windows but most people do not notice it because it appears as if built into Windows Explorer. It is great when you use the right applications and workflow. If you use open source editors that work across multiple operating systems, they do not show the Tortoisegit status indicators and you lose the advantage of Tortoisegit.
I use several editors on Linux. Some of them have the advantage of allowing plug-ins to add features. Some also run on Windows so you can use the same applications on your corporate computer. Unfortunately none have a plug-in for Git. To be exact, they have only a command line interface, which is close to the tin can idea but without the benefit of masking tape.
Git Extensions
Git Extensions is similar to Tortoisegit but not as well developed. Users of Git Extensions talk about reliability compared to old versions of Tortoisegit then then mention going back to the command line for things that they could do in Tortoisegit without having to memorise stupid commands. The current Tortoisegit is reliable compared to the other Git clients and Git Extensions has not progressed as fast as Tortoisegit.
Mac OSX
GitX
There is a fashion accessory company, named Apple, who used to be in the computer business and sell a free version of Unix with a decorative theme for the user interface. GitX, from gitx.frim.nl, is their Git GUI themed to fit the OSX theme. If you use OSX then try GitX.
The GitX Web site says GitX is similar to GitK, a Git GUI for KDE on Linux. Linux is practically the same as Unix and Linux is free, unlike the OSX version of Unix. Linux offers several user interfaces instead of the one in OSX. There are Git GUIs for most of the user interfaces in Linux. I use the Gnome interface after several disastrous attempts at using KDE plus a confusing user interface on the main KDE applications I attempted to use. Neither GitK nor GitX interest me. User comments about GitX frequently mention having to revert to the command line due to the limitations of GitX.
Conclusion
In the Git client area, you can use Windows and work in a 1990s style interface or you can use Linux/Unix/OSX and work in a 1970s or 1950s style computing environment. This is one area where there is a desperate need for someone to write a usable cross platform application designed for this century.
Git is too dangerous to use for version control.
Further reading
- Facebook Like
- Google Plus One
- Log in or register to post comments