I do not like git.
Let’s take the most mind-numbingly trivial of operations, I want to put a branch I have somewhere so somebody else can get it. That’s the whole point of distributed revision-control, collaboration.
That’s too fundamental to be covered in the git tutorial, after all, it wouldn’t be fun if it were that easy.
Happily, git has built in manual pages. And knowing a few other revision control systems, we can guess that the command might be push. And indeed, there’s a push command:
push Update remote refs along with associated objects
Maybe this isn’t going to be so hard after all, a quick git push –help and we’ll be laughing.
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.
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.
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.
<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?
My brain seems to have fallen out of my head, let me pop it back in and read that paragraph again.
<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.
It didn’t get any better the second time.
Some faffing around, guess-work and cargo culting what other people do seems to suggest it wants the branch name there. Well, why didn’t it say so?
Ok, that should be easy then.
quest util-linux% git push ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott/util-linux.git ubuntu fatal: '/srv/kernel.ubuntu.com/git/scott/util-linux.git': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly
I’ve had a few ex-boyfriends hang up on me before, and they were gits too.
There’s nothing in the manual page about this.
There’s nothing in the tutorial.
What the holy crap is going on?
Turns out, you need to create the other side first. Why the buggering bollocks can it not to that for you?
So, let’s try that. There’s some clues about this in the git init manual page, but I have to be honest and I begged for help (and mercy) at this point:
quest util-linux% ssh zinc zinc scott% cd /srv/kernel.ubuntu.com/git/scott zinc scott% GIT_DIR=util-linux.git git init Initialized empty Git repository in /srv/kernel.ubuntu.com/git/scott/util-linux.git/ zinc scott% exit quest util-linux% git remote add zinc ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott quest util-linux% git push zinc ubuntu Counting objects: 10652, done. Compressing objects: 100% (2545/2545), done. Writing objects: 100% (10652/10652), 19.10 MiB | 12192 KiB/s, done. Total 10652 (delta 8075), reused 10534 (delta 8013) To ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott/util-linux.git * [new branch] ubuntu -> ubuntu
Hurrah! At last!
No.
Not at all.
Firstly, pushing to a remote branch doesn’t make it visible in anything like gitweb. You have to do enable that.
quest util-linux% ssh zinc zinc scott% cd /srv/kernel.ubuntu.com/git/scott/util-linux.git zinc util-linux.git% chmod +x hooks/post-update zinc util-linux.git% git update-server-info zinc util-linux.git% exit
Ok, now does it work?
No.
Looks all ok, but if somebody tries and checks that out:
wing-commander scott% git clone git://kernel.ubuntu.com/git/scott/util-linux.git Initialized empty Git repository in /home/scott/util-linux/.git/ warning: remote HEAD refers to nonexistent ref, unable to checkout.
What the hell?
How can a push command succeed while leaving an utterly useless branch?
Don’t bother trying to find this one in the manuals:
quest util-linux% ssh zinc zinc scott% cd /srv/kernel.ubuntu.com/git/scott/util-linux.git zinc util-linux.git% rm HEAD zinc util-linux.git% ln -s refs/heads/ubuntu HEAD zinc util-linux.git% exit
Now it works.
In all that is holy, what, the, fuck.
Seriously?
My quote of the day:
“Git is hard to use if you are not used to its workflow.”
No.
Git is hard to use.
Here’s what I wanted to do:
quest util-linux% revision-control-system push ssh://host/path/somewhere
If it takes anything more than that, it’s fucked.
Ouch.
See also the manual section “Setting Up A Public Repository” on Git homepage:
http://book.git-scm.com/4_setting_up_a_public_repository.html
And about refspecs: see the EXAMPLES section on “git help push” manual. Git may hold several branches in a repository. With refspecs user tells what branches she wants update in the remote repository.
http://www.kernel.org/pub/software/scm/git/docs/git-push.html
Yeah, git update server is really stupid…
I don’t get why the UI is such a mess, but well, when seeing that the code consists of various languages.. no wonder the system is a mess.
Let’s take the most mind-numbingly trivial of operations, I want to put a branch I have somewhere so somebody else can get it. That’s the whole point of distributed revision-control, collaboration.
If you are still thinking in terms of setting-up your own ‘branch’ rather than cloning the repo, you are still stuck in old centralized VCS frame of mind. “Distributed” doesn’t mean the same old tool with just a different name but a different flow of work. That is why you need to unlearn a bit (not much though) before you can learn anything about a ‘proper’ DVCS done the right way.
bzr attracts a lot of people coming from CCVS background (especially SVN) because it offers the same workflow. That sounds really good to a person who doesn’t really understand the basic philosophy of DVCS but to the person who do, it is obviously a big flaw.
Pingback: The joys of Git | Lee's Blog
Although I now know I could easily recognise what the problems were in each of the cases you listed, it’s only through hard-earned and painful experience with fighting with git. Despite its getting better, git still needs a lot of improvement in the user-friendliness department. Posts like yours are certainly valuable for git’s developers, who would never stop to think about whethere such parts the docs are really accessible to a young user. They highlight exactly what needs improvement. Thanks, and may there be more of these!
First, make a bare clone of your existing repo:
$ git clone –bare ~/repo shared.git
$ touch shared.git/git-daemon-export-ok # if you want to export using git-daemon
Then, copy shared.git to your server using scp, rsync, or whatever.
The above steps are as documented in Setting up a public repository in the User’s Manual.
Let’s say you add branch new to your local repo and want to push that to new branch in the shared repo:
$ cd ~/repo
$ git push user@host:shared.git new:new
The above step is as documented in Pushing changes to a public repository in the User’s Manual.
Of course, you could also add a remote in your local repo and do it this way:
$ cd ~/repo
$ git remote add shared user@server:shared.git
$ git push shared new:new
There are variations on this depending on your workflow needs.
A lot of people seem to hate git before they get converted.
See you in a few weeks for an “OMG git is awesome post” !
Indeed, the more I use it, the more awesome it is, but yes, it can also be very frustrating trying to figure things out by reading the very legalese man pages.
By the way Scott, a simple git init foo.git ( no environment variables needed ) on the server, and a git push –mirror are all you needed. If you are wondering why the remote HEAD isn’t set without –mirror, it is because unlike BZR, a GIT repo isn’t limited to a single branch, so normally when you push, you just want to add or update a specific branch, not set the default branch on the remote repo. You also could have cloned from the HEADless repo by specifying the branch you wanted.
Go github or gitorious if you need to publish a (git) repository quickly.
gitweb (as in: web interface) doesn’t need git update-server-info run: this is required only for HTTP transport (fetching via HTTP).
About that book with a nice cover: I only found a shrunken version at http://mako.cc/talks/20050728-fork_or_not_to_fork/html_slides/img11.html. Do you have a larger version?
Your ‘git push’ experience exactly mirrors mine a couple of years ago. I’d hoped things would’ve improved by now
anonymous,
No, this is not a feature that comes with being a DVCS done right. I’m a git fan, and i agree this should have been fixed long ago.
Hi Scott, thanks for this. I’m using git most of the time now for VCS work, although largely not collaborating with other people. I’ve come via a brief flirtation with darcs. I’ve never used bzr. This is a good example of batshit crazy UI and people defending it have drank too much kool aid.
> bzr attracts a lot of people coming from CCVS background (especially SVN) because it offers the same workflow.
This is true: Bazaar does allow the same workflow as a centralised VCS, and that fact is a big factor in attracting users of tools that only offer a centralised VCS workflow.
Don’t make the mistake, though, of thinking “offers the same workflow” means “cannot use any other workflow”. Bazaar’s *default* workflow is distributed; the centralised workflow uses different options and commands.
> That sounds really good to a person who doesn’t really understand the basic philosophy of DVCS but to the person who do, it is obviously a big flaw.
If Bazaar was *only* allowing an old-style centralised VCS workflow, that would be a flaw. Since it allows (but doesn’t require) the user to choose a workflow, and even allows that choice to be made arbitrarily during the lifetime of a branch, it’s a big feature of Bazaar.
I may be missing something. How is the example right in the man page you cite not what you are looking for almost verbatim:
> git push origin master:refs/heads/experimental
> Create the branch experimental in the origin repository by copying the
> current master branch. This form is only needed to create a new branch or
> tag in the remote repository when the local name and the remote name
> are different; otherwise, the ref name on its own will work.
Hey Scott, all you had to do was rsync it to your remote host! I found the tip here: http://www.nardol.org/2009/2/19/git-basics-reversing-the-git-sucks-effect
There’s a whole lot of things you can do with Git… Taking some time to learn it surely pays back.
Pingback: Disputa de Beleza: Git versus os outros
Git is incredibly overcomplicated and mostly undocumented. It completely ignores the KISS principle and makes you feel less intelligent than you really are. It promotes a chaotic development model. You have to be brain-damaged to use that thing. No wonder the Linux folks make bad software.
A-fucking-men. Linux is full of whackos and really shitty software. I’d use SVN over GIT any day.
Pingback: Git | meta/LPAR
What the heck??
I wonder why it didn’t happen to me and all the *many* other people that I know… perhaps because we read a tutorial instead of trying to guess what to do?
Pingback: No more googlecode, say hello to git
Pingback: Reflections on a complaint from a frustrated git user | Thoughts by Ted
Pingback: Scott James Remnant » Blog Archive » Revision Control Systems suck
I applaud your dedication to one of the most ignored truths of software development: Power – Usability = crap.
The whole thing makes me curious about GitHub vs Bitbucket. Why is GitHub more popular? I suspect because Mercurial users don’t need BitBucket to shield command-line horrors from them.
aha, you’re obviously a woman.
Salvage, since when is “Scott” a girl’s name? Even if he was female it wouldn’t make his comments any less valid. How about you take your idiotic sexist attitudes and just fuck off back to your cave.
Git will have in the future “git init –remote=”host:directory” – the patches have just appeared on git mailing list (they need some work).
Git-publish-branch might do the trick a little easier, if this is something you have to do often.
i hear ya. git really and truly does suck. i hate it more and more each day i have to tangle with it. it takes up my development time and my sleep…. urgh i hear it was conceived by some genius or someone. some genius. well, definitely not a tool for me.
Pingback: philwilson.org » Blog Archive » Bazaar and Git
The point here is if you have to waste time wrangling with a tool to get a job done, the tool is fucked. GIT is well and truly fucked. 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.
I laugh long and hard at all the lemmings using GIT for things that do not call for it.
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.
Face it, GIT is too hard for some people. Just like “Math Class” is hard for Barbie.
Perhaps you should stick to SVN. Or just swap files on a flash drive.
Pingback: g0's status on Saturday, 27-Jun-09 14:33:00 UTC - Identi.ca
Pingback: g0's status on Saturday, 27-Jun-09 14:34:32 UTC - Identi.ca
What happened to the good old days when people learned how to use things before complaining? Git is based on a few really easy-to-learn concepts. Learn them, and the whole “mess” suddenly makes sense. The same is true of any complex system. If you want to use a powerful tool, you have to take the time to learn how it works or it’ll all end it tears. You might even find it saves you time in the long run — like the time it took you to write this infuriatingly ill-informed blog post.
Git is not hard:
git clone git@repo.com:gitrepo.git
–creates gitrepo dir
cd gitrepo
touch newfile
git commit -a -m “message for commit”
git push
updating:
git pull
Dunzo — If you’re trying to serve up a repo you’ll have much better luck with git-daemon than you ever will with mod dav svn and that awfulness.
This blog post made my day. After 3 hours of figuring out how to create a project (excuse me, a repository), check it out in my IDE, and then commit (excuse me, push) back changes, I read this. It echoes my experience of using Git for the first time.
@jowyhurtado mod dav svn awfulness: are you kidding me?
Add a url in a web browser and get a file back from the repo, even a specific version.
Check out a subset of the project and not the entire damn thing.
Track *actual* modifications to files and not just mark them modified because of a timestamp change.
Trvial management of dev and relese branches using svnmerge.
*actual* support with Maven’s release management.
Awful indeed!
My company changed from CVS to git several months ago. I hated it then, and I hate it now. It tries to be too clever, all the time, and it can be difficult to get it to do what you want it to do unless you understand all of the internals – and perfectly, at that.
git is, simply put, too difficult to use. It does have a few nice features, but overall I find it to be a pain in the ass.
Pingback: User Interface Design: the Command Line « UNIX Administratosphere
@Jose => Jumping from CVS straight to Git is humongous leap! Not too surprising that it comes as a shock to the system — it works on a completely different philosophy. I guess there’s no point crying over spilt milk, but I wonder if it might have been wiser to try another wiki-like system (e.g. SVN). It would probably fit your company’s existing workflow much better.
Adopting Git will usually require changing your whole approach to team development.
I’m going to be installing Git as well as selected Atlassian tools on an Ubuntu server for a software application company. This isn’t an open source project, so the corporate IP (source code etc.) needs to be completely secure on the server, and the server currently needs to support only a handful of remote developers.
I have been told most people are using VNC (RealVNC) for secure remote access to an Ubuntu server, but not sure this is relevant to the above. Is it useful to use this as part of the solution?
So as of today (late Sept. ’09), what’s the most straightforward, secure and effective way to set up Git on Ubuntu for a centralized server repository? (I understand local users have their own Git repositories they push to the remote server when appropriate).
Thanks for any help you can provide, as there seems to be a great diversity of opinion to do a relatively straightforward implementation.
I wouldn’t say git sucks. Rather its documentation does. Seems the git developers know that, but as usual everyone is willing to complain, nobody is willing to improve it.
@Eugene => The Git documentation is organised as a reference, rather than a walkthrough; maybe that’s what’s confusing people. There are hundreds of easy “getting started” guides for Git though. I don’t think there’s any shortage of good documentation for Git.
To be honest, I wonder if these people that say that Git sucks are really just looking for a reason to dislike it because of a preconception, or maybe they find it intimidating because it’s a different way of doing things?
@Paul: no, it’s because it *does* suck. For all the internal power, it’s *NOT* obvious how to use it effectively. Usability matters!
Please don’t start blaming the users because your tool is hard to use. It’s not just one person having problems, but many.
@Adam => Well, I’m not a fan of Mercurial because I don’t like that it’s implemented in Python. However, I don’t go around saying it sucks just because of a design decision that I don’t agree with; I just use something that suits me better. I actually really like Git’s interface—it makes perfect sense to me; that’s not to say it would necessarily suit you.
Everyone is different. Please don’t blame tools for choosing a way of doing things that you don’t like—there are an awful lot of people that love Git. It’s just the same as Vi/Emacs, Ruby/Python, Rails/Django, Drupal/Joomla. Use what you like, and accept that others may not think the same way you do. I guess this will become an increasing issue in the growing world of ‘opinionated software’.
I don’t like how git is not able to preserve empty directories, git also don’t handle binary files very well, that’s the negative side of it.
Yes, I second that—I do wish Git had a better way of handling empty directories. The “official” workaround is to stick .gitconfig files in each of them. It would be nice to have the option to store file metadata as well (not by default, but optionally).
I think Git does pretty well storing binary data though; how would you say it deas it badly?
git is to VCS as emacs is to editors.
Seriously. emacs can do anything short of shining your shoes – and someone, somewhere has probably written a few dozen thousand braces of Lisp to make it do that. (Or so its converts preach.) It’s written by geeks, for geeks; casual use is actively discouraged, new users have a very, very high learning cliff to climb up by their fingernails. And those who’ve gotten to the top of that cliff wouldn’t have it any other way.
That same mentality has gone into git – which exists only because of an entirely foreseeable, massive strategic farkup which drove a (functionally gifted) coder into a heroic effort. Use cases? Clean interface, ready for other tools to make use of? Handholding for new users – and EVERYBODY was a “new user”? Fuhgeddaboutit…
Linux geeks are famous for jeering at Windows “lemmings” who follow the crowd. Pot, you may already know Kettle…
lol, you again, of course you won’t let my reply to be on your page, but dude seriously you are incredibly biased, your employer gives the money to develop bzr (btw bzr sucks) your opinion on git is worthless you should concentrate on fixing bzr issues, if you think bzr is so good that it beats git, take a look at the emacs development list, they are really suffering because of bzr, they are using bzr for political reasons but many developers just hate bzr.
@lol (earlier comment):
No, YOU suck.
- Anonymous comment: -∞ for relevance
- “xxx sucks” w/o details on why: -∞ for commenter maturity and intelligence
- needlessly stomping on someone just because you disagree with them: -∞ for commenter maturity and intelligence
…
So… can you do better? Build something better than git or svn or bzr or LSMFT, build a community and an ecosystem/infrastructure around your new creation and make the world see how much better it is?
Didn’t think so.
Eff off. And grow up. Not necessarily in that order.
The point isn’t about “building a community and building something better”.
Current stuff works and it works with easily. Stuff people do everyday is plain and simple and works without pain on systems like SVN.
The point is the fact less bullshit proliferated about how this new thing is the best because it solves ALL these terrible problems that only certain people seem to think were problems in the first place.
I think a lot of the noise is because Git is created by someone who Git fan bois think is the most intelligent man on the planet. Ok, maybe he had a hit with Linux but in the music industry they have a term called “One Hit Wonder”. Maybe we have a “One Git Wonder” and the hit wasn’t Git!
Completely agree, it sucks! Much too complicated to use
I agree. Git makes it way to hard to do simple things. I’ve used SVN, CVS, Perforce, Mercurial, VSS. None make it as difficult as git. I always thought version control was supposed to be brainless, not an exercise in frustration.
Trying to use Git is like being on LOST. If you want to see ultimate half-baked suckage, try installing and using git on a Windows server and client. I was forced to give up and went with Subversion, a much more mature product with better integration with mainstream development environments, OS’s and IDEs, and semi-usable documentation.
@RoryR =>
Git was designed to take advantage of the way POSIX filesystem layers operate, particularly in Linux. It’s tuned to be *rediculously fast* on these systems. As a side-effect, performance sucks in Windows. The msysgit guys have done an amazing job just getting it to work semi-decently in Windows.
If you want something to work quickly in Windows, use Bazaar or Mercurial. They’re orders of magnitude slower on POSIX systems, but they’re more portable. That’s the tradeoff you have to choose.
@Paul: Fast for local operations, but still damn slow for that initial download. Every version control system is (or is that just DVCS? Haven’t done a SVN checkout in a while.)
Ironically, a tarball is the best option for the initial checkout.
Many seem to be in love with GIT (not here
)…
I, on the other hand, keep banging my head against the wall. Before someone says I must be an idiot – I’ve figured out more software with my eyes closed and hands tied behind my back, than you have… and whether this GIT has something great or not, it’s RETARDED! I’ve been using version control for 12 years – not only for software, but for CAD files as well… GIT doesn’t make sense to a newbie and quite frankly the docs aren’t cutting it.
Since there are projects I’m after that are using GIT, I’m GOING to learn it, but good gravey – WHY would anone love it? I don’t know… yet.
Tools like TortioseGIT or something else that removes Learning the BS – well then there’s a tool worth getting behind. PLEASE more people help out with the project and get it FULLY GOING!
Or could GIT just Git Itself Theeffouttahere!?
@Chris, you’re absolutely right. Other DVCS tools (Mercurial, Bazaar) seem to be more intuitive and robust while having less of a superiority complex. I’m starting to lump git in with emacs and perl: they’re the tools that put the ‘über’ in ‘übergeek’, but for those of us who just want to get things done in the easiest, most teachable and supportable manner practical, they’re completely counterproductive.
I don’t expect git to go away, any more than emacs has; neither has to be commercially successful, or even grow outside a tiny, self-congratulatory echo chamber of geekery where self-referential obscurity is seen as a primary virtue. As time goes on and the folks who actually WANT to get things done find the sharp edges, the differences between hype and reality, they’ll move on, leaving the echo chamber isolated and intact — which is what’s wanted, anyway.
Very poetic and insightful, nice!
you’re right on.
I’ve use lots of version control tools too.
Git has wasted hours of my time in the course of a week.
And it’s STILL not doing what I want.
Back to SVN for me.
Scott, are you gay? I am serious.
Scott, I was not trying to be rude, it’s just I thought you were funny when you wrote “my ex-boyfriends were gits too”. I thought at first perhaps you meant “girlfriends”. So, don’t take it the wrong way. I am not being sarcastic or mean. In fact I like the humour in your post.
GIT is totally fucktarded software…it tries to bend user into its illogic workflows, does not follow any estabilished CLI principle and creates all sort of weird statuses and operations. I have found impossible to mantain a kernel git clone with a few patches because it automagically screws up itself, and no way it won’t pull without merging, and it won’t merge without commit, total nonsense!
And, furthermore, the bastards at kernel.org don’t allow you to remotely export the GIT trees – because they want you to use their lovely software. Fuck that.
Oh boy. I cannot agree with you more. You are absolutely correct. It is complete shit.
Our organisation just moved from svn to git and it’s been an unmitigated disaster! We *need* submodules, and submodules in git is all the pain of git multiplied by a thousand.
I just want to say thank you.
I just spent my entire morning and several hours over the last few days trying to figure out how to use GIT to track changes and push updates in my single server/single user environment. After deciding the solution was too ridiculously convoluted and would actually take more time than my previous workflow, I typed “git sucks” into Google and this was the first result.
I wonder if any of these circle-jerking basement-dwelling GIT fanatics have actually been in an environment where “time is money” and getting shit done is more important than changing the way things are done (even when it makes things worse).
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 shit.
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.
Sigh.
“refs” is git’s name for a branch name. Push sends a local “branch name” to a remote “branch name” and sends all the data necessary for that branch to work. there. simple. exactly what you want.
dhbanes:
on your server you can ssh to, type git init –bare repo.git
on your client, type git clone server:path/to/repo.git
now put all your stuff in the new ‘repo’ directory
git add
git commit
git push to send stuff to the server
if someone puts stuff on the server, git pull to get stuff.
Git sucks. I know you said that, but I wanted to re-say it. Here’s a little conversation I had with git the other day (not verbatim):
Me:
Me:
Me: "Oh that looks funny. But, hmmm, it doesn't look like an error in my code. Maybe it's an error in someone elses code and I can fix it with an update.
Me: git pull
Git: No, you changed something before I'll even look to see if the changes can be merged you've got to commit it.
Me: Well I'm not really comfortable with that, my code might have an error.
Git: You must commit
Me: -sigh- git commit
Git: I got some new code and merged some stuff.
Me: Run. Well that was no help. I'll roll back my changes and see if an earlier version works.
Git: Hah! How about a hash key sucker.
Me: A hash key? Really that's the best way to approach this? You couldn't have a mature GUI, or maybe an simi-readable naming system?
Git: Hash key now puny human.
Me: Fine what are my keys?
Git:
Me: git reset
Git: Now your files are exactly as they were, but one isn't committed anymore.
Me: Of course, because that was really the simplest way to approach flagging one file as "not committed". I don't suppose we could actually hide that file somehow.
Git: I have a complicated n-layer deep stash we could put it in to. Everyone on the web advises you never bother with the indexing this supports because who really wants to stash a dozen things then retrieve the 7th layer?
Me: git stash savethis
Git: I put it in position 0. Of course, your files haven't changed because I did a merge after the change you just uncommitted and then stashed and I consider that the head.
Me: Yes you do you little darling. git reset --hard
Git: Fine, whatever, but it will all end in blood. I think we know that by now don't we?
So, yes, git sucks.
@David,
This is an amazing script you wrote and yes GIT S U C K S for sure. I don’t like it and that’s it. I don’t need someone’s opinion to change my thoughts. I truly agree with the author that GIT sucks.
@Chris,
Lots of people especially in open source community loves lots of bullshit products but that doesn’t mean everyone should use it.
Rails community is adapting lots of useless stuff which is relevant to their mind boggling complex systems but that’s not a case with every language. Take PHP as an example. Simple, short and sweet
GIT SUCKS ! IT REALLY DOES !
I’m supposed to use this crap here since it is a defacto corporate standard. Not that I’m a noob in development … but yes it definitely sucks and I’m happy to see I’m not alone … Way too complicated !
I agree with you!. Git sucks!
This forum can be described as one with “selection bias” – meaning that the nature of the matter is such that the very people who actually dislike GIT will be the ones compelled to share their opinion in the comments, while people who like GIT will feel less compelled (the older the post is) to bother with argumenting. Supportive behaviour is easier to maintain than opposing behavior, especially on Internet. What I am trying to say is that this post along with the weight of its comments, however insightful, is hardly ANY indication of quality of GIT. It is simply to be taken as a study into statistics – that there indeed are people who dislike GIT, and I am glad they are heard. I wish you guys complaining would at least explain your gripes with it.
amn, are you gay? I am serious.
@D.H. Banes: you are not serious, you are lazy. Just read his other blog entries.
Back to the subject, I can only repeat what others said. Git sucks. It may be a perfect toy when you understood all of its internals, but: this is about five times more and more complicated than what you need to know for… say, subversion. And this stuff is likely to be forgotten if you don’t use git on daily basis.
There are just too many f*ckups in the UI. They used words with established meaning for totally different work (checkout to check it out? ROTFL). Some commands are just freaking dangerous because they work both ways depending on the context, they can examine or modify, or both. And if you manage to make something wrong, it doesn’t help you much. The error messages are mostly brain-dead or seem to be written by people with completely different assumptions in mind. Different from what a “normal” new users tends to think at the moment when she is trapped.
And the worst part, this crap seems to hit some nerve in many people turning them into fanatic missionaries. Then they stop listening to arguments… like in “Brave words. I’ve heard them before, from thousands of species across thousands of worlds, since long before you were created. But, now they are all GIT.”
@Dude
amn says:
May 16, 2010 at 12:29 pm
Scott, are you gay? I am serious.
@D.H. Banes: ok, got it wrong. Let’s wait for amn’s outcoming. *g*
Lol I thought I was the only one…git is retarded imho. If projects I’m interested in isn’t using git, I would never touch it.
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.
Git, like just about anything open-source, is chock full of maddeningly idiotic usability descisions, pointless ignorance of conventions (everyone knows what a ‘branch’ is, why rename it to ‘ref’?!) and totally impenetrable documentation.
Luckily, unlike a lot of open-source software, Git is actually phenomenally awesome once you get your head round it, even on Windows, where it performs somewhat like a dog. It *does* take a lot of getting used to, but once you understand the fetch-branch-merge-push workflow, its really fast and transparent, especially if you like branching, which you should do and will if you learn to use Git properly.
It does take some getting used to, and its not as idiot-proof as some version control systems, but if you’re comfortable with the command line I think the benefits easily outweight the cons.
Git does suck. I can give you many examples why it does suck. Here’s just one of them.
I have a github project on a server let’s call that project canonical/master. I fork that to my own remote server called origin/master. Easy…
I clone the origin/master branch to my local drive and code away.
After several commits I push to my origin/master branch.
In the mean time others have been working on canonical/master so I need to rebase to make sure I have them. Now the craziness starts.
I do:
>git fetch canonical
>git rebase canonical/master
Now it tells me that files that only I’ve been working on need merging. This makes no sense as I added them and have never pushed to canonical/master. I ask around. Nobody has created a file with the same name.
On inspection of the files to be merged I realize that they were previous commits of one file
WHY THE HELL WOULD I MERGE WITH PREVIOUS COMMITS. I CHANGES THE DAMN FILES FOR A REASON.
After working through this pile of crap I decide I should update my origin/master.
Now I get some fast forward error crap and the manual says I should rebase against the remote branch.
I do that,
What happened.
THE REBASE I DID AGAINST CANONICAL/MASTER IS BLOWN AWAY.
Git is retarded. version control systems should be easy to use and not take developers time away from developing good clean code and following best practices. I would say that git is not a best practice.
it’s UTTER SHITE
GIT sucks
I just tried to understand git. I think it requires a PhD.
And, I don’t like the idea that all my “branches” are not real
branches that live in real, separate disk folders but magically
appear in the same folder where there are 100′s of other things in
the .git folder. It is really not for me, wonder what I’m missing
and do people who use git find it easy to use? Very beneficial? I
simply need to spend a few days/months I think..
Yeah, I couldn’t agree with you more. I’ve torn my hair out with git at times, when in fact, SVN was smooth sailing. I think not all problems are worth hitting with a hammer (git). Some just need a gentle tap (SVN).
Besides, I think that SVN is much more bare-bones, and it is fairly simple to understand what exactly it is doing. Coming to terms with it is much easier, and frankly, as a developer of _another_ application, learning a new version control system that demands my undivided attention is not something I’m looking forward to.
Seems that ‘Paul Gideon Dann’ simply believes everything anybody clever ever says to him. Sitting here bashing everyone for bringing up legitimate complaints about git, quoting Torvalds endlessly (code-wiki etc, ho ho ho), doesn’t *actually* make you look smart. It makes you look like a dildo.
For everyone else, I don’t really think it’s enough to just say ‘git is easy, look!’ and paste in some commands. Fact is, some very typical workflow involves multiple steps, when other systems – the ones that are supposedly fundamentally broken – allow it in a single step, allowing me to get on with my actual job, not fight my VCS all the time. Acting like we’re all morons for wanting a virtually transparent VCS isn’t cricket
kthxbye
Git sucks. Sure, you get it for free. Just like cancer and malaria.
The UI is the worst piece of design (and code) ever made, the documentation is a joke and the error-messages are consciously insulting its users.
Shouldn’t git just be under the hood of another tool that does what people expect? Slap the hg interface onto git, and we have a winner. I’m thinking CVS/RCS.
I’m sure I’m completely wrong in some way, it just seems like the tools of git can be powerful, it’s the glue that is missing…
I needed to build from linux-next so I went to kernel.org, got lost for way too long, and finally found git, built it. I ran git clone and left it. Not sure how long it took but it was a lot longer than dl a kernel tar.bz2. Then I built a kernel from that. Time passes…. I made no changes. I want to sync to get any changes. git pull runs and runs and runs and I get a signal 9
Then I set merge.renamelimit 1677 (cuz it said to), re-ran git pull. It churned
away for a long time, at least an hour. Eventually my laptop siezed up and required a hard reboot. So now I look into some other way to keep a linux-next src tree current. Git: “We made the hard things work, but someone else can fix the rest, because it works here.”
coreboot switched to git without a transition period and the project died.
Has anybody here tried Mercurial before?
I agree Git isn’t too good, but at least it is better than Subversion for sure in the sense that it makes it easier for multiple contributors to contribute, as well as avoiding issues with having a single repository for all the code that has the potential to break when a wrong commit is made, and in addition it can make collaboration very difficult.
With DVCS you can pull changes from another person’s repository and incorporate those changes, and then send the new changes along etc etc until it eventually makes it (or doesn’t) into the main repository.
One of my main issues with Git is the lack of native Windows support, it was designed specifically with UNIX in mind. Hg on the other hand is designed with Windows support in mind.
But one system that is easier to use than Git would be Mercurial – it is much easier to use. No need for over-complicated command line gibberish in Hg either. And there’s TortoiseHg for Windows users.
I should also add, Git also has some features which help detect corruption more easily, and the fact that it doesn’t litter the file system (and rather, it keeps its versioning into one “.git” directory in the root, as opposed to a “.svn” directory in all the directories in the repository for Subversion) and in addition cloning/pulling is in general noticeably faster than Subversion checkouts.
So Git does not completely suck, at least definitely not compared to Subversion or CVS for example, but at the same time the UI and multiplatform support should be improved.
Git is horrible. Seems ok until something goes wrong then you’re whole project is screwed.
I have to agree with everyone who says Git sucks.
Been using subversion for many years and never suffered any of the so called *problems* people bang on about:
Corrupted repositories? WTF?
Slow updates?
Branching issues?
Problems with having a central repository? WTF? Who doesn’t one to have a central place that is the master repository. Name me one commercial product using git for version control that doesn’t have a master repository.
“Ooooh look at me I’m so anti-establishment now that I’m a Git fan boi”. Give me a break!
Maybe if you have 22,000 source files like the Linux kernel you might find git useful but for all the pain and experiencing no pain currently with subversion I’d have to say that git has collected some unwarranted hype.
This is coming from someone who has just blown the last 48 hours of his life trying to checkout, make a simple change and check in to a github repository. 48 hours I’ll never get back…
I’ve been an SCM administrator for the last 20 years, administering at least 8 different source control systems across many operating systems. I can describe major shortcomings and benefits of all of these source control tools — well, except for Visual SourceSafe because it has no benefits. VSS is 100% downside.
More to the point, I’m not just some developer who loves subversion (it’s just OK) and doesn’t want to learn new processes. I ALWAYS want a better tool. Change is my career.
So when some friends and trusted former teammates recommended that I look at git, I was pretty stoked to find out more about it. I did all kinds of reading and asked a lot of questions. And what I’ve read and heard makes me think, without ever installing git, that it’s not an improvement. The syntax is inconsistent, verbose, nondescriptive of the actions — just horrid. It is poorly documented and requires a sea of web tutorials to show you how to do simple things like the one described in this article — and even that might require you to scan 20 hardcore blogs.
I love perl. It’s not for everyone, and it can be arcane and inconsistent. But you can learn to write a quick program in a few minutes and you can get actual work done almost right away if you have any programming experience. On the other hand, this article explains a situation that any git user should NOT have to think too hard to solve. Yet it turns out that one does have to really work hard to figure out the right answer. Then comes the chorus of git apologists who say that Scott didn’t read the right tutorial or instruction manual and that it was way easier if he only knew the right double-bucky-three-finger-salute. THERE is your unusability. Just because you know where something is documented doesn’t make it obvious to everyone. Might as well be writing APL.
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).
I wholeheartedly agree. I’m a contractor, who wants to get paid for software development not waste hours on git.
Pingback: Git… enough! – The Scribbler of the Rueful Countenance
Git is easy to set up and use locally, but a huge pain for pushing stuff. If it wasn’t easy to set up and use locally it would not stand a chance.
It’s a little bit of a bummer to see people still having so much trouble with Git: once I learned to see the commits as nodes in a DAG and the branches as pointers to specific nodes, it just clicked for me, and my usual Git workflow is nice and smooth. I hope you come across some good tutorials. I like John Wiegley’s Git from the bottom up because it really brings across the idea that you’re really manipulating very simple structures in Git. And most of the time you can even just ignore blobs and trees and just focus on commits and how they’re related.
Agree on every word. git wastes hours and hours of our development time. It was developed by Linus and Co for their specific needs – merging huge Linux branches and replace bitkeeper. Workflows are illogical and overcomplicated. Try to for instance check out a remote branch. Does anybody remember the right command line keys from memory? I doubt that. People who in love with git are either those who know all guts and bolts of it and sit on git mailing list watching for every single change or those who do merging of branches day and night.
Haha…here I am, after several hours of trying to figure out how the hell to create a working copy from a repo I just made. git pull? git fetch? I dunno…many tutorials, and not a single one seems to address something as simple as “how the FUCK do I make a copy of my shiny new repo and get productive work done?” Sorry, world…git might be the shit, but I’ll stick with svn, thank you very much.
And my favorite Christmas present? Typing in “git sucks” and landing on this page. That certainly made my day.