Re: svn versus git

On Wednesday 2006 December 13 22:56, Shawn Pearce wrote:

Yes. I was a little unfair on that one; I forgot about the REV:file syntax. However, it's still not simple for a new user; I think I'd say "draw" if the "-p" weren't a requirement.

Yep. Especially when combined with the fact that the command is called git-cat-file. A new user could be forgiven for thinking that meant that they could cat one of their files held by git. Also: they have to read a man page to find out that they need an option and which option is correct. I reckon git-cat-object would be a better name ("no chance!", I hear you cry ;-))

I've just noticed as well that the documentation is wrong:
 $ git-cat-file HEAD:Makefile
 usage: git-cat-file [-t|-s|-e|-p|<type>] <sha1>
The square brackets indicate "optional", and those items clearly aren't.  I'll 
fix the documentation.

My point is that a user can run "svn cleanup" without thinking, or needing to really know what it does. Not so for git's maintenance commands. Also, there are more commands. I'm not saying they're not useful or necessary, but it's certainly more complicated than subversion.

For example: I used subversion for a long time - I don't think I ever had cause to run "cleanup", I'm not even really sure what it does. I /have/ had cause to learn what git's maintenance commands do; which in turn meant I had to learn how the git repository works. (I personally don't mind learning those things, but it's wrong to expect every user to do so).

Me too. I've never run it in fact; but the command exists and therefore needs learning.

Hurrah! However, at the time I wrote the comparison (and with 1.4.4.1.g3ece-dirty I've got here) git-merge is still the old, more complicated, command line.

Absolutely. Although, even if SVN does implement it, it's going to be a hack. It'll just be an extra svn:special property set somewhere in the repository, or similar. I can't see how they can do merges properly with the methodology that SVN uses.

You're right; as it happens I'd prefer it if git could store empty directories. However, in terms of "what I have to learn", git definitely wins this category because there is nothing to learn - make whatever directories you like; it will generally sort itself out.

$ git-ls-tree v1.0.0 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8 Makefile

I'm a newbie: what's that number at the front? What's a blob? What's that great big number - I've only seen commit hashes that look like that, and that isn't one. Definitely not friendly.

$ svn list -r 14 Makefile

It could probably be fixed by making git-ls-files capable of understanding tree-ish.

You are correct of course. They don't need running regularly, and in a way that makes it worse. How is a user who isn't familiar with git internals meant to know they should run git-prune? How are they meant to know when they should run it? How are they meant to know that it is git-reset, et al, that create conditions that need them to run git-prune?

Personally I like my repository pruned fairly often. This makes it much easier to find the commit I need to restore when I've accidentally done a git-reset I didn't mean to. If I had to search through three months worth of dead objects it would take me all day. However, I don't think that affects a new user at all. Recovery from disasters should be expected to be hard.

Yep, /I/ know.  How is my imaginary new user meant to know?

My rhetorical questions are the key to making git friendly I think. Each one represents a hole - it's not that there is no answer, it's that there shouldn't be a question. The hard part (as always I suppose) is that we have to imagine a new user; this makes all my babblings above highly subjective. As such I won't be that upset if I'm told to "blow it out my ear". Whatever that means.

Andy