Skip to main content
Topic: It's official: 77% of people think Git sux donkey ballz! (Read 2187 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

It's official: 77% of people think Git sux donkey ballz!

And they're right too.

http://amplicate.com/hate/git

Quote
Seems brilliantly designed to match the intuitions of demented ferrets
Quote
Intuitive as creating a nuclear power plant with pasta and glue


And, from another source: http://netsplit.com/2009/02/17/git-sucks/

Quote
Maybe this isn’t going to be so hard after all, a quick git push –help and we’ll be laughing.
Quote
DESCRIPTION
Updates remote refs using local refs, while sending objects necessary
to complete the given refs.
Ok, err, not quite sure what that means; but it sounds like it’s doing something over there with what I have here. Probably the tool I want.
Quote
You can make interesting things happen to a repository every time you
push into it, by setting up hooks there. See documentation for git-

receive-pack(1).
I’m not sure I want to know about making interesting things happen right now, I’ll just settle for some boring making-things-public.
Quote
OPTIONS

<repository>
The “remote” repository that is destination of a push operation.
See the section GIT URLS below.
Aha! Now we’re getting somewhere. I give it an argument saying where I want to push to, that all makes perfect sense. A quick skip down to the URLs bit tells me I can use ssh, which is what I want.
There’s one other mandatory argument though.
Quote
<refspec>…
The canonical format of a <refspec> parameter is +?<src>:<dst>;
that is, an optional plus +, followed by the source ref, followed
by a colon :, followed by the destination ref.
Err?
*blink*
Whuuuuh?

Which sums things up pretty well.

Apart from the bitching from GitN00bz, there are also considered opinions from very experienced people.

http://netsplit.com/2009/02/17/git-sucks/#comment-1827
Quote
The point here is if you have to waste time wrangling with a tool to get a job done, the tool is gently caress. GIT is well and truly gently caress. I know what DVCS is, where it is (and isn’t) useful, and where it is (and isn’t) superior. Some of GITs guts are very well coded (despite being a hodge podge), but the interface SUCKS, SUCKS, SUCKS.

Stop and look at your workflow and your use. If you don’t actually need GIT don’t inflict it upon yourself (or others). If you don’t know enough to know whether or not you actually need it then DON’T USE IT because you’re going to cause trouble for yourself (or others) as a result.
 


And http://netsplit.com/2009/02/17/git-sucks/#comment-1862
Quote
1-Our company introduced git/gerit on Feb 2010 as ‘source control’.
2-Since then every developer productivity decreased more than 60%.
3-Our git experts spend theirs entire wd dealing with the fudge nuggets.
4-I have more than 20 y experience in programming, and I have not seen anything worst than.
5- If a programing/handling tool takes more then 10% of the total development time is a damn worst tool.
6-Mouse was invented almost 40 years ago.


A very detailed case study here: http://netsplit.com/2009/02/17/git-sucks/#comment-3345

Quote
I’ll chime in here too.
I’m a contractor, every year I work for a few different companies on a few different projects, so I get to experience a lot of stuff and have a pretty pragmatic approach to everything.

I first encountered git a few years ago (2008, I think), a couple of guys were using it on a subversion project and I was quite interested. They did a lot of pushing and pulling from each-others repositories which seemed like a useful capability, but most of their technical conversations over those 6 weeks seemed to revolve around trying to get git to do something, or why it looked like X on one machine and Y on the other. I concluded this was something I would take a serious look at when it was a bit more usable.

Fast forward to this month, and I’ve been brought in to lead development on a short and frantic web project. We’re using git, so, I spent the best part of the weekend before kick-off learning and playing. After ample experimentation I ended up using TortoiseGit for nearly everything, dropping back to the command line (a PITA on Windows) when learning new stuff in order to properly use the meagre docs and tutorials.

First, my personal experiences as a developer:

* Setup on Windows, to get it working with a remote repository on Gitorious, took about 3 hours – mostly mucking about with key pairs (tortoisegit requires the putty kind, gitorious a more standard variety, which can be exported from the putty key).

* General use is fine, the paradigm of committing to the local repository and pushing/pulling changes makes sense. A couple of annoying days when I forgot to push changes to the server before switching machines – with svn I know my committed changes are always available everywhere, with git it’s an extra thing to think about.

* Too much destructive power is available too easily. Git lets me really screw up a lot of hard work if I don’t think (harder!) about what I’m doing.

* This concept of pushing/pulling changes between local repositories has way too much overhead (dynamic dns, troubleshooting firewall/ISP problems) unless everyone’s on the same LAN or it’s a huge project. When I need to share my branch I’m pushing it to the remote server and other people are grabbing it, pretty much like SVN with a couple of extra steps.

From a whole-project point of view, it’s been a nightmare.

* 6 developers (5 contract, 1 perm, varying abilities/experience, mac/windows mix) all starting on the same day, deadline 5 weeks, hit the ground running, etc.

* By day 5, 3 developers were able to reliably commit and push changes, and two of us had spent at least half our time helping the others.

* By day 8 (!) all developers were able to reliably commit and push changes.

* Day 9, we reduce to 5 developers. The least productive guy went, and he also had the most git problems – hard to tell which way the causation lies, he wasn’t great as a dev but wasn’t below average either.

* General impressions: I remain cautious and everyone else has been reduced to the level of a techno-illiterate grandmother, frightened that she’ll unintentionally break something with the slightest click in the wrong place. Routine practice before using git for at least 3 team members is “zip the directory”.

So we definitely, without question, lost about 230 hours of productivity entirely due to git issues. Let’s say average developer day rate is £350, and that’s £10K. Utterly insane, shouldn’t happen.

On top of that, the workflow of local commits have caused a big problem when it comes to collaboration and integration. It’s impossible to know what someone is working on until they’ve finished it, and then it might not workwhich means you have to ask them. We all know how important ‘flow’ is, right?

Well, every time you have to ask someone if they’ve started work on thing A yet (because if not you’ll do it) you’ve interrupted their flow, and probably nuked about 15 minutes of their time. Let’s say everyone gets asked that a few times a day by someone, when with a centralised system they could just have checked the commit log, and over the life of the project we’re talking about another 100 hours wasted.

VCS shouldn’t be harder than coding, but git plainly is.

Commercially, we should accept that not every developer is in the top 20% of developers (they are not all Linux kernel hackers) and source control software really really needs to work for EVERYONE or it wastes all our time.

I’ll stick to recommending SVN for clients who haven’t implemented any form of VCS yet (usually at least one a year, even now).
 


And perhaps most interesting, this one: http://netsplit.com/2009/02/17/git-sucks/#comment-1874

Quote
We use svn at work which sucks big time (absolutely useless at merging and tagging is a con). So I started to use git svn because of its great integration with svn. I had previously used Monotone and found that to be VERY reliable, had great visualisation tools and brilliant at merging.

At first I was very impressed with Git, easy to compile/install, bundled GUI tools. After a bit I found the GUIs rather limiting. Then it came to merging in Git and svn checkins. What a mess. Git was pretty useless when it came to merging in comparison to Monotone (random files deleted from master that I hadn’t touched in my branch, random line ending changes (cross platform project) in files I hadn’t touched etc). After spending a few hours cleaning up the post merge mess I ditched Git and switched to Monotone and used svn_load_dirs.pl to load back into svn my revisions. Now I have something that works flawlessly and allows me to use the back end svn repo (mandated by the project).

If you want a free, very reliable, cross platform no fuss, `just works’ DVCS then look at Monotone. One of our projects at work has 6 supported release branches, up to 40 releases each branch, 100s of current dev branches (all changes done on their own branch etc). The build manager spends a matter of a few hours merging in ~20 branches to prepare a release, he swears by it. Not even ClearCase would make one this productive.
 

That sounds like something useful.

http://en.wikipedia.org/wiki/Monotone_%28software%29

http://www.monotone.ca/
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: It's official: 77% of people think Git sux donkey ballz!

Reply #1
Much better than SVN.

3 commands cover 85% of the common usage, for the rest there is google. :P
Bugs creator.
Features destroyer.
Template killer.

Re: It's official: 77% of people think Git sux donkey ballz!

Reply #2
Meh.

 TestMonkey thinks that a more productive reading and linking sites would be for those which state again the obvious commands. It's only a tool to commit stuff, not rocket science.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: It's official: 77% of people think Git sux donkey ballz!

Reply #3
Meh. Well my New Year's resolution is that I'm going to ignore the silly thing. Every time I try to use it, it gives me the fudge nuggets. So, I'm going to treat it like any other software that gives me the fudge nuggets, and simply not use it. Easy. :)
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: It's official: 77% of people think Git sux donkey ballz!

Reply #4

Much better than SVN.

3 commands cover 85% of the common usage, for the rest there is google. :P
You mean the 3 R's .... Rebase, Resolve and Revert ?
Squish squish. squish, squish, squish.
Find a bug,
Make a wish.

Re: It's official: 77% of people think Git sux donkey ballz!

Reply #5
 emanuele doesn't know 66% of the commands Spuds posted...
Bugs creator.
Features destroyer.
Template killer.

Re: It's official: 77% of people think Git sux donkey ballz!

Reply #6
Well hey, there is one good thing on GitHub. We should implement support for these: https://github.com/joho/7XX-rfc
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: It's official: 77% of people think Git sux donkey ballz!

Reply #7
Silly buggers made the mistake of asking for feedback and saying they'd love to hear from me. :D
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: It's official: 77% of people think Git sux donkey ballz!

Reply #8
quiter
Success is not the result of spontaneous combustion, you must set yourself on fire!