GIT sucks
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.
[...] posted that Git sucks, citing the yak-shaving necessary just to push a branch to another host for publication, and the [...]
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” !
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.
[...] diversas manifestações pró e contra o Git, vindos de empresas que lucram com ele mas também dasque perdem. É interessante, no entanto, que reside na simplicidade do Git sua aceitação e alcance atual: [...]
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.
[...] publish it now”. Trying to achieve this with git led one developer to post a series of rants: git sucks part 1, part 2, part [...]
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?
[...] And stop crying for Ubuntu sake
This entry was posted in Linux, Mint rubbing, Open Source, Planet, Thoughts. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL. « Launchpad.net, OpenID and delegation [...]
[...] Scott James Remnant posted a series of “Git Sucks” on his blog, starting with this one here, with follow up entries here and here. His problem? To quote Scott, “I want to put a [...]
[...] recent series of posts in which I had some difficulty with GIT (1, 2, 3) have garnered a lot of interest, and generated some discussion. Many of the replies saw [...]
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.
[...] systems as a whole, and the git command set in particular on Revision Control Systems suck and the series of posts he links [...]
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.
[...] http://ur1.ca/1qoy [...]
[...] http://ur1.ca/1qoy I thought this is another of those ironic fun blog posts, that sexist got a nice bashing in the [...]
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.
[...] which are absolutely a gem (albeit from way back in February 2009). He wrote an article titled Git Sucks – which was then followed by a second and then a third – followed by yet another titled [...]
@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.