Geek rants on git
thefuriousgeek.com
Geek rants on git
1–10 of 17 posts
Re: Geek rants on git
#2Just because something failed for you, doesn't mean it failed for everyone. One of the author's main points is talking about GIT GUI's, which I think is his/her primary problem. Terminal based programs, nmap, git, gcc, emacs, vim, etc. Don't lend themselves to GUI-ization easily. To attempt to categorize their vast functionality in terms of drop down, or pop up menus and buttons is largely an exercise in futility.
Personally, I'm more excited to see a blog post from the author working on a headless server for the first time. I think he could give a wonderful review of the Bourne Again Shell.
Re: Geek rants on git
#3Re: Geek rants on git
#4Waste of parsing time from my part. Save yourself 20 seconds and don't read this.
"Fatal error: Out of memory (allocated 3670016) (tried to allocate 7680 bytes) in /home/auroand/public_html/thefuriousgeek.com/wp-includes/l10n.php on line 530"
Re: Geek rants on git
#5For anyone who would like to work with Github but prefers svn. I can't personally speak to how well this works but it is available.
(OT: I first found out about svn support from a presentation by Zach Holman, I believe you can find it here: http://zachholman.com/talk/git-github-secrets/ Some interesting bits in there. )
Edit: fixed spelling
Re: Geek rants on git
#6Yes, Git has complex UI but so does Microsoft Word - if you want to be efficient at using those, you need to spent some time learning.
Re: Geek rants on git
#7Re: Geek rants on git
#8Branches: Especially if you work on a team, but even if you work alone, you definitely want branches. Often you'll want to work on an experimental or not-production-ready feature or refactoring. Yet you'll still need to be able to jump to the production codebase and maintain it, e.g. when a high-priority bug is found. Branches assist you in this and other scenarios.
Local commits: You shouldn't need to rely on the network just to save your progress.
Cloning: Every developer's Git repo is a complete copy of the main repo. That gives you an automatic backup system for every project. If you've ever seen corruption in a central SVN repo, you know how important backups are. Yes, with SVN you could implement your own backups for the central repo, but with Git, it's one fewer thing I have to do.
Adding a.k.a. staging: If you've changed a bunch of files but only want to commit a subset of the changes, it's nice to be able to add them incrementally. The alternative is to have to type out all the paths in one big commit command, which isn't as user-friendly.
Re: Geek rants on git
#9Are there any notable projects that try to accomplish this?
Re: Geek rants on git
#10But, two things:
The author is, of course wrong about git vs svn safety. Once you really know git, it is more forgiving than anything else. Almost all mistakes are recoverable. Not so for svn.
The author is right about git having a usability problem. Git is hard to learn. I'm sure some of us had the same initial reaction. Personally, I'd love to see someone put a gui skin on git that uses different terminology, picks the most newbie friendly defaults, and makes the workflows easier. P4v, for example, is easier to use than Sourcetree or Tower or other GUIs that basically only give you menu options for the things git does. Not saying that p4v is the awesomest, but I've watched artists manage with p4v, and artists largely don't in git.