Jason Clinton replied to my virtiolic rant about GIT with a well researched and thought out reply. Sorry, that’s not what I mean. He replied to my rant against a piece of technology with a personal attack.
I feel that there’s a few points that I need to reply to.
Romeo Tango Foxtrot Mike
I did, in fact, the vast majority of my post was excerpts from the Foxtrot Mike. It was the Foxtrot Mike that was half of the problem.
and because the company you work for has a horse in this race and they can do no wrong
What does this having anything to do with anything? The company I work for develops many pieces of software, and a quick bit of searching will find people who work for the same company (including myself) complaining just as loudly about them.
Sometimes, sadly, it seems that people in the open source world are unable to separate other people from the companies that they work for. Ironic, given the high turnover, and frequent moves between the different companies that most people seem to go through.
I am not Canonical. I am not on the Bazaar team. I have been involved in open source since long before I joined Canonical, and I will almost certainly be involved long after I leave Canonical.
Most importantly, I am able to hold my own opinions, and I am able to form those opinions without influence from my employers.
If you don’t believe me, just go back a couple of years and look at some of my rants about Arch, and the first Bazaar. Ask for a copy of my book, “Arch is easy, and other lies the developers may have told you.” It has a cool cover.
GIT reminds me a lot of Arch.
My personal opinion about this is that Arch (and now GIT) is the first distributed revision control system that people try, and then they get it. They understand why distributed revision control is so awesome, and they attribute this awesomeness to Arch (and now GIT) rather than realising that it’s an inherent property of any such system. The learning curve is pretty damned steep, so there’s a lot of investment to learn Arch (and now GIT) and once people have made an investment in something, and received an epiphany as an award, they become very attached to it and very aggressive about attacks on it.
and because you can’t be bothered to look up what you want to do first
Again, it should be clear from the post that I had spent a very long time trying to look up what I needed to do and found no help.
From the very same Git Tutorial that you were about to link to in a giant section titled
Using git for collaborationyou could, you know, look at the command you think you might want:
Have you actually read that? I have, yesterday as it happens. All of the examples are with bob and alice working on the same machine, it makes a brief reference to the two being on different machines but then assumes that bob can access alice‘s workstation.
Utterly useless.
And since you’re a very smart person with a history of working with VCS’s and a resume a mile long in the FOSS community, you know that that’s a giant red flag that you’re about to force the tool you’re using in a mode that is not distributed.
And as you can clearly see, I was trying not to do so. I was simply trying to push changes from my workstation to a server from which alice, err sorry, lamont could pull them. If I am picking the wrong commands because of familiarity with other systems, then frankly GIT is being perverse in deliberately using commands in a different way. Even BitKeeper used push for “make your changes public”.
You say that I’m using the wrong command? Well, let’s try and figure out from first principles what command I actually want. git help should tell us:
The most commonly used git commands are: add Add file contents to the index bisect Find the change that introduced a bug by binary search branch List, create, or delete branches checkout Checkout a branch or paths to the working tree clone Clone a repository into a new directory commit Record changes to the repository diff Show changes between commits, commit and working tree, etc fetch Download objects and refs from another repository grep Print lines matching a pattern init Create an empty git repository or reinitialize an existing one log Show commit logs merge Join two or more development histories together mv Move or rename a file, a directory, or a symlink pull Fetch from and merge with another repository or a local branch push Update remote refs along with associated objects rebase Forward-port local commits to the updated upstream head reset Reset current HEAD to the specified state rm Remove files from the working tree and from the index show Show various types of objects status Show the working tree status tag Create, list, delete or verify a tag object signed with GPG
Any of those strike you as doing what I want? I imagine that getting changes from your workstation to a web or git server is a sufficiently commonly used command, after all, even the kernel developers all publish their branches on master.kernel.org.
Well, it’s clearly not add, or fetch. merge? pull? no. reset? status? no.
You know, reading that, I really might think that the right command is push.
The git(1) manual page gives even more commands, one of them looks really appropriate:
git-send-pack(1)
Push objects over git protocol to another repository.
The manual page on this instantly refers us back to push.
DESCRIPTION
Usually you would want to use git-push, which is a higher-level wrapper
of this command, instead. See git-push(1).
If push really isn’t the right command, perhaps the Foxtrot Mike could stop referring to it everywhere?
Now, it happens that I received some helpful replies as well. You clearly know the right command, and even manage to mention it, but not in any kind of helpful way. Another kinder soul was much more helpful.
clone is the right command, it can take two arguments and the first argument can be “.” while the second can be a remote URL:
quest util-linux% git clone --bare . ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/scott/util-linux.git
was what I actually wanted. Curiously nobody in the #git channel seemed to know about this when I was asking for help.
Users coming from other revision control systems will probably equate clone to branch, or checkout or some other similar operation. It probably won’t occur to them that they can reverse the arguments. This should definitely be prominently documented.
And no, the GIT tutorial never gives this example. It’s always clone remote to local.
Random aside, I discovered that bzr supports bzr branch local remote as well; neat.
Someone else tried to be helpful, but ended up simply being amusing. They suggested that I use git format-patch to extract my patches and then send them by e-mail.
Can I just say that if your revision control system is so bad for collaboration that patches must still be sent by e-mail, then something is deeply, deeply wrong.
To finish up, in a comment on your own blog post you say:
All the documentation in the world won’t help if even smart people like Scott decide not to read it and demand that git work exactly like bzr does. Which is exactly what happened here. Again.
A quick bit of checking would show that the example I gave wouldn’t work with bzr either. Bzr needs a silly “bzr+” on the front of the URL, there’s a lot of fail there too.
Good response. How about a patch for the documentation?
Well, FWIW hg needs the same command (clone) and coming from bzr to hg (almost 2 years ago) I experienced exactly the same situation but frankly I do think that the one that has got it wrong is bzr and not git (nor hg), moreover the git help clearly states “Clone a repository into a new directory” so I can’t see what’s difficult there, that’s what you wanted to do and that’s exactly what clone does.
Pingback: Scott James Remnant » Blog Archive » GIT sucks (3)
Well, I’m no git master, in fact, I hardly use it at all. I do, however, have this site to offer:
http://www.newartisans.com/blog/2008/04/git-from-the-bottom-up.html
Might be more useful.
This is – sorry – very amusing to me
The thing is, getting Documentation right is very very hard. And you know that of course.
Writing a documentation for somebody who already knows the tool to a sufficient degree is already hard, but achievable. A lot OSS projects out there kindof manage this. If you know what you’re looking for, you’ll find it. Easy.
It’s however a hell of a lot harder to write a documentation that works for someone who is not used to the tool, doesn’t know the nomenclature used etc. Look at VTK vor example. They have an API documentation and a book. Without introductory examples, you’re lost. Git feels much the same. I’ve had the same pain when I started to use git.
There is exactly one project I know of which gets this really right – and this is Qt. Why:
- They have plenty of documents explaining in simple terms the concepts behind the technologies involved
- They have a thorough API documentation
- Each class-documentation is accompained with some introductory text about what it’s supposed to do and some code snippets on how to use it
This way, it’s very easy to get to learn a certain piece of Software. Git has improved, but it’s not there yet.
So why is this amusing to me? You look like a small child smashing the table because your mom doesn’t give you the cookie you wanted
What I find annoying is the tone of Git supported. I don’t want to use Git only because of that. Each time you criticize Git (and in a constructive way, suggesting possible solution), a pile of Git supporter fall on your back, screaming “Bazaar Nazis kill babies” and stuff like that. I’m astonished that when some bright hacker like you or Thomas say that Git is too complicated, they are called “too dumb to use Git”. I discussed with some people at FOSDEM who told me that they abandonned Git only because of the community. This is really sad…
I’d definitely agree that Git’s docs suck. I’m trying to make learning Git a bit more piecemeal and approachable through http://gitready.com
Perhaps take a look through the Git Book as well: http://book.git-scm.com
> A quick bit of checking would show that the example I gave wouldn’t work with bzr either. Bzr needs a silly “bzr+” on the front of the URL, there’s a lot of fail there too.
bzr+ssh:// is simply bzr:// tunneled over SSH. If you want SFTP, try sftp://
Scott, if it’s helpful, I think the documentation from the git user manual is helpful.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
Particularly, “4. Sharing development with others” has a nice section subtitled “Public git repositories”:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#public-repositories
“So why is this amusing to me? You look like a small child smashing the table because your mom doesn’t give you the cookie you wanted”
Way to go with the ad hominem attack there buddy!
I found Git painful, but I love working with Hg. I know there isn’t really a huge difference between them, but Hg only exposes the commands I would actually use. Git’s low-level legacy makes it harder to pick up than necessary.
TortoiseHg was also a factor, since for lazy pointy-clicky people like me such frontends are a plus – Even in the current, highly unpolished state.
Wait, you’re leaving Canonical?
Get a life
You mean to say you can use clone to push a repository from local on to a remote machine using ssh? I’ve been using git for a while now and I never knew that! I thought it only worked the other way around (as it is used 99% of the time I would guess). You’re quite right – this needs to be documented properly!
The way I’ve always done it, and the way I’ve seen other people do it, is to ssh into the remote server, init a bare repo and then go back to your local machine and push from there. It’s tedious but if you only have to do it once…..
As much as this whole exchange may have riled a few feathers at least we can say it’s been productive. I’d hazard a very large percentage of git advocates didn’t know you could use git clone this way and if this exercise has educated them (as it has me) as well as forced a change in documentation to help newcomers in future then everyone wins.
Pingback: git monthly links: 2009-02 « git blog
I’m not entirely sure the bzr+ is silly… after all, it indicates that it’s using the bzr protocol over an ssh connection.
Also, using branch/clone/checkout to push up a repository isn’t too much of a weird idea, but indeed should be documented and, I think, the push command should support that case aswell (pushing where nothing exists).
The “reverse clone” does not work for me at all:
% git clone –bare . ssh://pulse/home/madduck/.tmp/cdt.TdhCIC/test.git
Initialized empty Git repository in ./ssh:/pulse/home/madduck/.tmp/cdt.TdhCIC/test.git/
It would be so nice to have too!
lol, you work for canonical, you are so biased, of course you will say git sucks, your employer tells you to do so, the reality is that bzr sucks donkey balls big time, look at the emacs project, developers there are SUFFERING because of bzr suckiness…
…must…not…feed…trolls…… ***** ARRRRRGGGGGHHH***** (brain explodes)
Any preteen-mentality (pretend-mentality?) Anonymous Coward who signs itself ‘lol’ and begins its comment ‘lol’ should automatically be ignored. I propose a patch to the WordPress comment system, such that
– the trigraph ‘lol’, upper or lower case, in the ‘name’ area causes the message to be deleted and the originating IP to be blocked from all WP sites; and
– any comment containing two or more of said trigraph in the comment text triggers the same treatment.
LOL STFU!!1
Pingback: Git | meta/LPAR
The problem here is quite clearly your own stupidity and/or technical ineptitude. By this point, a huge number of high profile and well respected projects have either migrated to git or are planning to do so. Look kind of stupid now don’t you?
No. Git is still badly documented.
You know what’s more useful than trying – and failing – to score cleverness points off someone else? Actually addressing the problem they’re having. Try that.
Bzr may be “well documented” but it’s unintuitive, dumbed down and painfully slow. Using LaunchPad is an exercise in frustration.
On the other hand I find git very intuitive, it gets out of my way (as all good tools should) and it’s blindingly fast.
Bzr is a straight up POS, but I expect nothing more from a distro with a community composed largely from people like this: http://omgubuntu.co.uk
Actually you’re the one that looks foolish because you attribute popularity to usefulness. The simple fact is git has a steep learning curve. You can bullshit around that if you want, but it is what it is.
All trolling aside, some points (I apologize for somewhat ranting in advance, but lets be real here):
1) Like Linux, git is technically extremely awesome…
2) … “under the hood”. But also like Linux, it fails on understanding the unfortunate low motivation or intelligence (or both) of the real world user base, and fails to understand that ramp-up time and productivity are king. For example, I’m spending my weekend now powering my way through the documentation and trial-and-error, setting up gitosis, getting the highly un-intuitive egit eclipse plugin to work, etc. Now, mind you I will get there soon enough, but I would much rather be doing something else like coding on something I actually care about, but actually I’m more or less ok with this part because the software is free and I don’t look a gift horse in the mouth.
3) However – now here’s the fun part folks. After setting all this up at work, instead of doing what I get paid for (writing code), I will get to spend hours step-by-step walk through each of the Redundant Array of Inexpensive Developers (RAIDs) I work with on how to use this toolset. I know this because I already went through it with SVN. To 90% of the RAID drones that work at any decent-paying company, documentation is like some kind of kryptonite. Instead of going through this painful process also, or using that mysterious web site (google), they would rather just, “Hey can you…” or “How do I…” when it comes to creating branches or merging their own code. So, I then get appointed to be the “branch manager” and the “merge gimp”. Jeez it’s bad enough I already have to dick around with maven on everybody’s machine 3 times a day because the eclipse plugin can’t maintain project state correctly.
4) Reality: Git was designed for Linux kernel developers, who generally have more going on upstairs than 90% of the corporate drones who have a very simple and limited workflow:
— checkout / setup project
— implement code changes
— test their crap
— check it in
— if there is a branch, merge – hopefully in some way that sucks less than svn
… which by the way implies a need for about 4 commands for the common use case. Most developers have a very average level of intelligence (not being condescending here, but by definition, most of anything is average). Its probably more of just trying to get their actual job done rather than screw around with tools that are not intuitive. Rebase and cherry-pick are great features, but I’m telling you the drones won’t use them unless a tool can dumb it down much more than git does. I’m thinking maybe something on the level of a video-game for 9 to 14 year olds might work.
5) No, Hg and Bzr don’t handle the workflow much better, these systems really all just copy features from one another as far as I can tell with some trivial variation.
6) To summarize, here are my general interface design questions:
— Why so many steps? Why do changes need to be add’ed, then committed, then push’ed when one command will do? Don’t tell me it is so you can work offline, if you are offline, it could just queue things locally, while of course gently reminding the drone that he needs to get connected at some point to get the changes upstream. Git confuses working offline/offline with the user workflow itself here.
– Clone vs Pull vs Fetch? Huh…? Dude, seriously its one command to update from server to my machine.
— Why just allow a random email to be entered? In a corporate environment that makes it a hard sell for obvious reasons. Of course you are going to make all the obvious kumbaya answers about “Well, if you can’t trust developers blah blah” and I both get it and agree with you. However (again, reality) is that sometimes (not often, but sometimes) bad drones to dumb or evil things — hence the need for a thing called real security. Of course I don’t want to hear romance stories about how you spent a weekend hacking it to do X or Y… I have a real life.
To reiterate – not knocking git technically in terms of nuts and bolts, it is quite awesome — DAGs and all. But maybe another layer of scripts can be put on top of it to make it usable (call it gitiot, maybe… or gittyup… or gitter-dun?).
Anyhoo… as much as SVN merges drive me nuts and I would love to use anything else… I’ll probably sticking with SVN at the corporate drone contracts and maybe using git or Hg for my personal projects.
Git as a tool may not be terrible, but git as a documented piece of software is awful. I say this as a newbie. It is a terrible newbie tool to have to try to use. Right now I have a project to upload and you should be able to say “Git, upload this stuff to that location using ssh.” Now there may be a way to do that, and this might be the number one most common task for a newbie to want to do, but no git –help is gonna tell you how to do the most common thing the tool is supposed to do. Apparently git was designed to be used by people who already use it. Terrible, but then again, it’s free. Terrible is good enough for free, I guess.
This post is right on even 3 years later. I’m looking for the commercial answer to git. “It’s free so I can’t complain even though it is a pain in the ass to use.” is the worst attitude in FOSS-land. I’m willing to pay money for a real tool that has the benefits of distributed version control but that doesn’t suck ass to use. (Any suggestions?)
I challenge you FOSS weenies to use your giant brains to do something really hard: make intuitive software that’s easy to use. But, that’s a lot harder than calling people stupid and telling them to read the documentation. Good software doesn’t require you to peruse tomes of documentation in order to figure out how to perform the most basic use case. You gits are still content with the dancing-bear.