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.
The sentiment here is terribly funny when you realize that SVN came from the same group of people. Good work, guys! Generalization is not your strongest talent.
IMO, Git is great.
I’ve been coding for 15 years. GIT is horrible. Most mundane task: commit/ push gives slew of random errors one in five times. incredibly stupid for server deployment especially. Versioning should work for me, not the other way around.
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.
What does being a woman have to do with this topic? I think this implies some kind of insult. If that’s correct, you are mentally ill.
Wait a minute, why is this post even here? Who is “moderating” this site? Had this been racial, would it still be posted here?
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.
No, you are retarded, git is fine.
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!
Argh, brainfart, I shemoow completely missed the third paragraph The git svn branch part is really just the branch creation (like svn cp trunk branch ). After that, you should have a new remote tracking branch (see git branch -r ) and can rebase your stuff onto it, like:git rebase onto $new_svn_branch master $git_branchWhat that does is that it turns the commits in the range master..$git_branch into patches, applies them on top of $new_svn_branch and then updates $git_branch to reference the result.And then git svn dcommit -n should tell you that it’s going to dcommit your stuff to the new svn branch.
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..
<>
I have a PhD – and that is the most important inhibitor to understand git.
If you are trained to learn by analysing and systematic rules, you are lost (as I am) with the git command line interface.
I unfortunately have to use git because I do some Linux kernel stuff from time to time… But I never managed to properly track new developments on the kernels. These rebase/reset –hard stuff is something I never can remember over moths. So every now and then I spend a lot of time googling how to do it. Sometimes it works, other times it doesn’t.
If I want to save my time, I just do a rm -rf && git clone. This is most likely not that the inventors of GIT have expected…
And because tutorials were mentioned – I have worked through some of them but they *always* end there where the problems start.
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.
While git was created specifically for kernel development, it is rather flexible, and if you give it enough thought, you should be able to come up with an usage model that suits your team (piss poor usability aside).
For example, in kernel development, there is one repository per subsystem at http://git.kernel.org/, with each repository containing the full source code.
Meanwhile, KDE has one repository per module at https://projects.kde.org/projects, with each repository containing just the module.
These 2 projects have different workflows, and both benefit from git.
The reason why so many people hate git then, is because the person who brought git to the team often didn’t think it through.
As an example from my own experience, in a typical ~5 devs team, each of us was assigned one public repository to sync our code with. This is bizarre as one canonical repository was enough. I have much better things to waste my time with than dealing with pull requests.
This is why, as a lazy developer, I much prefer hg which comes with this: http://hginit.com/02.html
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.
Pingback: git smash | Scott James Remnant
I love git! I use it daily with 5 web-developers and we never have problems. We have never lost files, commits or anything. We also have several local branches each for experiments and certain tasks which we merge and push and pull from and to with ease! All of these “git sucks” stories I read (which I don’t know why I googled in the first place) are by people are using it for the first time, working on a project with a deadline and expecting it to work the way they think it should. Are you people on an old terminal or something with no internet access? I understand the idealistic view that man pages should be sufficient, but whenever I have a problem with git I open up my Internet browsing software, type google.com into the address bar, type in my problem in the search field and voi-la!: Someone already had my problem and posted the answer! Do you people not know about this?
Ok, excuse the sarcasm there but I am a big git enthusiast and it makes me sad to read all these negative comments about. All the problems listed here I have had before and just took the time learn how to get through and now I have no problems and have knowledge of an incredibly powerful VCS. Again, I have NEVER screwed-up a project before, even when less knowledgable co-workers push weird things, every problem can be worked through with ease when you have TAKEN THE TIME to learn how the software beforehand.
If you really want some kind of wrapper around it, check out Git Tower (for Mac).
PS, I have never used git with Windoze and never plan to so I can’t refute any claims again it.
PPS: http://gitready.com/ is a great resource!
I agree with you. I think GIT is more powerfull for developer only, or say it master developer, not for end-user or the learner. Yes, we can learn a bit of GIT. But GIT system it’s not only for one direction like any other daemon. It’s look like so simple from beginning when we think it’s only like upload and download operation. But there are somewhere who only need to get some sources, for example, how it very complicated.
I am using GIT to get source: stable and development for some packages. But it so confusing that make you headache on large project source like Linux kernel and any other large project while I was only want the stable one and the latest development tree one to trying it.
The big problem is we cannot resume the clone operation on bad and unstable connection.
I really really wanted to learn Git because everyone is gaga about it, but after 3 unfruitful nights trying to get a copy of a repository i created on another machine, I am close to concluding that Git is a huge, steaming pile of festering shit. WTF Linus?
I’m inclined to agree. Why does this tool have to be so confusing? Why do we have to type crazy-a$$ commands instead of a clean, simple, GUI like DropBox? This is 2012, not 1985, right?
Thanks for this post! git well and truly does, suck. Unfortunately all of the Linus fanboys refuse to believe it.
I’ve used a few different (D)VCS now, and my current pick is bzr. Your “git push ssh:…” would have worked (almost… the syntax is a little different) as expected. bzr (unlike git) knows how to create the repository on the remote, from the client-side. You don’t even need bzr on the server (ex: bzr can push to ftp://), but it helps.
If you think setting up a remote git repo sucks (ironically, git really only works well if you have a centralized repository, e.g. github), try merging. git is pretty braindead when it comes to merges, too. I had to resort to patch files today (!) because git just couldn’t figure things out.
I have read the whole blog and it’s both entertaining and informative. All the name calling and posturing aside there seem to be good reasons for either using or not using git depending on who you are and what you need it to do for you. Having finished reading this blog I didn’t want to use it fearing it to be non-user friendly, awkward and providing facilities I probably don’t need. However a colleague of mine has persuaded me otherwise and shown me how he uses it for his own projects.
As someone who has only ever used CVCS I now realise that my greatest problem with Git is that the conceptual act of “Committing” changes does not do what I typically expect. I think most users of CVCS expect a “commit” to physically take changes from a local workspace and place them into a repository on a separate device somewhere. The moment you realise this is not the case people get worried.
I understand a bit more about DVCS now and this no longer troubles me. Also I’ve found a nice looking GUI front end called SourceTree (for Mac .. not sure about availability on other platforms) Clearly there is more to understand about Git than most other version control systems but I’ve managed to do few simple things with it and I’m going to give it a go. Hopefully I’ll not be back with stories of great woe, because frankly like everyone else has said, I just want to get on with my work.
You people who hate Git are missing out is all I can say. That or you just think that anything that doesn’t come naturally must suck. That’s about as mature as writing off people who like it as fanboys. Congrats! Maybe you’re all just really young and need to grow up a little. I have never had a problem with Git after the initial learning curve. Merging in particular is always super fast for me, even when I have lots of conflicts. I guess I’m just really, really smart (I’m not).
One of my favourite parts is that committing isn’t committing to another device (as stated in the last post there). Basically, after every change I make that completes a piece of the idea (branch) I am working on and has my app in a stable state, I commit. That way, if I make changes to stuff I have just changed and back myself into an undoable corner, I can revert to the point I was at before I moved on to this next step. When it comes time to push to the central repo, I can squash all my little commits into one nice succinct one. Not sure how anyone can argue that is a bad thing but I’m sure some genius who has just decided they hate Git will find a way.
And to make a comment about people making fun Git claiming it has no central repo, of course there is always a central repo. What Git does is allow ANY copy of the repo to be the central one as a clone gives you the entire history of the project (all deltas in ONE .git directory). If the one your project has decided is the central one somehow gets corrupt or deleted or whatever (github gets hacked, perhaps), you can copy over anyone’s repo who is working on it and use it as the central one. In other words, you have as many back-ups as you do people working on the project. EFFICIENT!
The only true negative I have read here is that you can’t resume a clone. This is true and is totally lame BUT you can always just grab the repo by other means (like S/FTP) and link up to a remote afterwards. It’s a work-around, but it works. Oh yeah, it’s also a negative that you have to put in some time to learn the technology therefore receiving no instant gratification. *sideways glance*
Why make something like version control such comlicated? Are all git users write such perfect code? There is none argument for git, besides that when you using is as distributed system(leutnant workfolw). Have a locale repository, but why, your locale machine can crash, and everthing has gone. So plz concentrate on good conding and architecture. Thx have to use it but do not like it, i see no advantages (fast cloning it only needed once, so it’s a joke to use it as advantage; fast committing yes, but how often do you use this? You should wirte a complete module or an task before checking in)
have a nice day samgam
@Andrew
> “That’s about as mature as writing off people who like it as fanboys. Congrats! Maybe you’re all just really young and need to grow up a little.”
Andrew, this might be true if Git was the only DVCS or if all of them were equally hard to use. Thing is, they aren’t, so the argument “it’s your fault, not Git’s” doesn’t hold water.
Someone wrote that most people who think they like Git actually like DVCS, not Git specifically. The workflow you describe works in any of them. There aren’t many who argue that this is a bad thing. Actually, most quite like it. But they argue that Git is a bad thing – compared to the other DVCS.
I happen to agree with them, but I don’t hate Git. I know it’s kind of unpopular to not absolutely love or absolutely hate stuff, but really, I just get along a lot better with Bazaar and Mercurial.
Coming from CVS and SVN, I tried git without reading the documentation and was thoroughly confused. ‘Git sucks!’ I thought. A few months later, I spent about 6 houts reading the documentation (git-scm.com), and now I enjoy git immensely.
gitantilover wrote the following:
(fast cloning it only needed once, so it’s a joke to use it as advantage; fast committing yes, but how often do you use this? You should wirte a complete module or an task before checking in)
I think gitantlover is using old CVS/SVN terminology. You should NOT write a complete module or task before checking it in in git. Think of local git check-ins more as saving your file. Every day, multiple times, you save your file in a CVS/SVN project. If you want to get back to the version you had 2 hours ago that you did not check in, what do you do? You have to save those files manually (or have something like Eclipse that will store these for you). Some important save-points would be ‘local commits’ with git.
The git push is what you do when you would do a normal commit in CVS/SVN.
The same issues happen if your machine crashes in either git or CVS/SVN – you lose everything since your last push (git) or commit (CVS/SVN) unless you have local backups.
Yeah, I was overreacting a little, it’s just that it seems that everyone ragging on git chose to start learning it by using it for the first time on a project with a deadline, then they go and make all these false claims about it when it doesn’t work how they expected. One that I hear often (and has been mentioned here) is that it offers too much destructive power too easily. This is absolutely not true; you can back out of 99% of the actions you perform, you just need to know how (git by default essentially has 30 days of undo). This leads to another common complaint which is, “Why is it so complicated to learn?” I’m not gonna argue that it is user friendly (it could be waaaaaay more use friendly) but with its complexity comes a lot of power, and with some diligent study its syntactic idiosyncrasies will make perfect sense FOREVER. What bothers me about these complaints is that it really speaks to the laziness of our society. Truly powerful tools are going to have A LOT of functionality that will take A LOT of time to learn. Vim is another prime example of this; I spent a good 3-4 frustrating months practicing and getting good with it, and now that its core functionality+ has become second nature, it’s like cocaine. It feels awesome to use and I am editing text in a more efficient and, far more importantly, fun way than I ever was in my favourite text editor. The kicker is that I still have a lot to learn, and that’s ok. Vim lets me do things I always wished I could do in the past but just assumed were impossible. The problem is that everyone wants instant gratification and no one understands that if you put in a lot of time up front, it’s going to collectively save you an exponential amount of time in the future. Again, I made learning git a project in of itself. I tell you it has never been the cause of me losing ANYTHING. I swear! I love that it is a command line util since I can pipe its output and blah blah blah. I know that everyone is different but honestly, if you don’t get off on this shit then why did you become a software developer in the first place???
Anyway, I’m done here but since I certainly put in too much time into defending a piece of software, I am no real advocate for saving time. I will reiterate, though, that the biggest reward of these tools is that once you understand them, they are realllllllly fun to use (and do save you lots of time). No joke. I’m also drunk.
Pingback: Free GIT repository hosting | rizwaniqbal.com
I use bzr, I don’t wanna learn too much of VCS. I’m not short of storage nor bandwidth. I want EVERYTHING AS A BRANCH so my work don’t die easily. Simply.
Ahh, yet another perfect example of how cvs/svn cause brain damage, making otherwise intelligent individuals do crazy things. Git isn’t complicated, it’s simple; trying to do cvs/svn stuff in git is complicated.
So, in cvs/svn a repository is a magical mysterious “server” thing that normal users can’t understand. In git, it’s a folder. See? Git simple; cvs/svn complicated.
Now, with this new found knowledge, how should Scott have copied his respository? Surely he knows how to copy a folder? Of course he does! He’s already got ssh set up, so why not just:
[code]scp -a ubuntu kernel.ubuntu.com:/srv/kernel.ubuntu.com/git/scott/util-linux.git[/code]
And that’s it. Done.
But because of the corrupting influence of cvs/svn, look at the horrible steps he went through! Just to copy a folder!
Git is simple. Forget the appalling lessons cvs/svn have taught you and learn it fresh….it’ll save you a lot of grief…
Hmm…didn’t realise the code tags wouldn’t work. Oh well, you can see what I meant…
Some people try to show themselves as geniuses who understand git completely and love it. ok, you are! I don’t care, I am an average person who worked on tons of enterprise java applications with different version controls. I found GIT terrible tools to work with specially in a big team. so many conflict and merge problems. We are spending huge amount of time to resolve these issues. to my opinion git may be good (only may be) for small distributed applications/programs that developers works in distributed development environment which allow them to promote their code versions separately but for large scale application with many developers it really sucks . again I don’t care how people are hands-on or smart are in their world with any platform or technologies they use. In my world and around me, almost everybody complaining about this stupid and complex tools and the time we have to spend for just check-in our code.
Pingback: Revision Control and Unit Tests Considered Harmful | Scott James Remnant
Pingback: Ubuntu developers: Scott James Remnant: Revision Control and Unit Tests Considered Harmful | Linux-Support.com
Pingback: Scott Remnant: Git e i DVCS uccidono la creatività | oneOpenSource
What is amazing is that 2-3 years on these problems with git haven’t been fixed. Creating a git repository is such a ballache (for some insane reason git init doesn’t create a working repository, you have to hand edit a bunch of stuff before it’ll work.. miss something and you get a nonworking repository) I gave up and put everything on bitbucket.
Even with someone else taking some of the pain, it still sucks. How does it manage to balloon a directory that’s 700mb in size to 2.2 GIGABYTES of changes to upload, based on changing two or three files? WTF is it doing?
Git is just used by by linux geeks (1%) and linux geek wanabees (99%) that want to think that they are smarter than everybody else, but well, aren’t.
If you want to use a repository, and just want it to fucking work, use mercurial. If you are in the 1% of actual geeks you wont be reading this because you’ll be too busy coding something (kudos to you). If you’re in the 99% wanabee group, go fuck yourself. You’re really not that smart. Deal with it.
We git reppers aren’t geniuses, and you haters aren’t stupid, though you may be stubborn — and probably a little bit fearful — when it comes to learning how to do something you already know in a new way. Just leave your reservations at the door, pretend you are learning source control for the first time, take a few deep breaths and then take a good few days to learn git. And for the Love of God, learn it using a test project, not something that has to be production ready in a week (jeeze you guys, really?). Pro Tip: Google all your errors (like copy and paste with your mouse… yeah, people who use git have and use mice too!). You should be pleasantly surprised how awesome it can be.
…or you can go back to back to calling us “fanboys” and “geniuses” all those awesome and oh-so-mature nicknames you come up with. Git is really nice software, guy (yeah, I’m Canadian), but it isn’t for everyone. Just don’t go publicly ragging on it, please!
Glad I stumbled upon this blog. I have been a software developer for 8 years and have used CVS, SVN, ClearCase, Mercurial and I just cannot understand how to use GIT correctly. It is definitely unuintutive and documentation is too technical. We shouldn’t need to know so much about the internals to use the tool.
Well I started out using RCS back in the main frame days then when to Delphi and used Starteam – which was one of the best solutions with a really nice GUI. Onto CVS and its quirks but quirks were okay as long as you just followed check in/check out protocol everyday. Then along comes SVN and its new-ness proclaiming to make collaboration better. Not bad but a merging nigtmare sometimes. Now we come to Git, which seems to be written in a different mind set. Okay I can see it’s usefulness. But the setup is horrendous with an IDE like Eclipse. The help out there is like linux, there are 20 opinions and flavors of how to do things and not all are correct for my situation. The GUI’s for these are clunky and chock full of errors. When you have a conflict you can sometimes get in this catch 22 of in Merge mode but there are no changes. I’ve had to reclone git to be able to get it to work in eclipse…ugh, but its suppose to be the better solution. I’ll wait and see, but I do miss the simpler times of check-in/check out
. Oh well onward with git, until the better solution comes.
I’ve used Git, Mercurial, and the also-ran Bazaar. I listed those in decreasing popularity but increasing usability. For everybody who says, “You just don’t understand distributed version control properly!” why is Mercurial so much less painful? Try Googling for how to fix conflicts. Only for Git is the top response a Stack Overflow question boiling over with frustration. It really kills me that Git appears to have won the DVCS war.
GIT F*cking sucks! I hate it, I said it. I should cool off now…
Totally agree with you. GIT turns the most easiest thing into a beast. Without knowledge about how GIT internally works it’s impossible to get it working. Using github doesn’t make anything easier. it seems like i have to edit a config file to specify my github credentials, why the hell it doesn’t just ask me like any other vcs does? And at the end there are nonsense error messages. good bye git.
Pingback: GIT: a Nightmare of Mixed Metaphors – Ventrella Thing