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
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
