Subject: Re: svn versus git

From: Andy Parkins <[email-masked]>
Date: Thu, 14 Dec 2006 09:08:34 +0000

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

>   git cat-file -p $REV:$file
>
> not sure how much easier it gets than that.  Load in the bash
> completion from contrib/completion and you can even tab complete
> the $file part.

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.

> Documentation flaw that the above wasn't clear?  Or is "-file" and
> "-p" the losing part for Git?

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.

> > svn cleanup::
> > git fsck-objects::
> > git prune::
> > git repack::
> >
> > Subversion wins, as it only has one command and you don't need to
> > understand the repository in order to understand what its doing.
>
> True, but I'm not sure its fair to Git.  svn cleanup is also a
> technical command that one needs to learn either when something
> went wrong or later once the user has gotten used to using SVN.

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).

> The last time I ran fsck-objects was when I was trying to debug
> that empty tree object missing in git-merge-recursive.  Usually I
> don't see repository corruption, and even there wasn't any.

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

> or git merge now.  :-)

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.

> This is one of Git's killer features over SVN.  Git does merges
> right.  SVN doesn't.  Though I keep hearing its on their TODO list.

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.

> Some people like having the empty directory tracked by the VCS, as
> then the build system doesn't need to create it.  I perfer keeping

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.

> How is it unfriendly?  What specifically would you change to make
> it more friendly?

$ 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.

> >  - svn cleanup: git-fsck-objects, git-prune and git-repack all need too
> >    specific knowledge of git.
> >
> >    They also need running too often on the user's initiative.  It would
> >    be nice, for example, if git-reset, git-rebase and git-branch could
> >    detect when a prune is going to be needed and give the user a hint.
>
> You don't want to prune every time these happen.  When you start to

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?

> make use of the reflog pruning too often is a huge loss.  I actually
> maybe prune my active repositories once every couple of months,
> the extra garbage hanging out is usually peanuts.

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.

> As to the former it depends on your OS (Windows you want to pack
> more often) but git-count-objects gives you a good indication of how
> many loose objects exist.  git-fsck-objects probably only needs to
> be run if something is not working right and you suspect an object
> is missing.

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