Re: svn versus git

[Shawn Pearce <spearce@spearce.org>]

Andy Parkins <andyparkins@gmail.com> wrote:
> svn cat::
> Output the contents of specified files or URLs.  Optionally at a
> specific revision.
> git cat-file -p $(git-ls-tree $REV $file | cut -d " " -f 3 | cut -f 1)::

better:

  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.

> Subversion wins.  This is a distinctly non-user friendly way of reading
> a file.

Documentation flaw that the above wasn't clear?  Or is "-file" and
"-p" the losing part for Git?
 
> 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.
Git's fsck-objects, prune and repack aren't usually needed until
the user has had a chance to use it for a while and accumulate a
number of loose objects.

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.

> svn merge::
> Apply the differences between two sources to a working copy path.
> git pull::
> Pull and merge from another repository or a local branch.
> 
> It could be argued that "pull" is a bad name for this command.  Apart
> from that however, git-pull is significantly easier to use than svn
> merge.  It's output isn't as easy to understand, as it dumps loads of
> confusing information to the user.

or git merge now.  :-)
 
> Git wins.  Once you've used it, it's nowhere near as terrifying to use,
> because it can be easily undone.  It's harder to do damage because git
> tracks merges whereas svn doesn't.  It's better at merging.  You will
> spend a good five minutes thinking about what you must type for an
> svn-merge.  git-pull is a no-brainer.

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.

> svn mkdir::
> Create a new directory under version control.
> [no git equivalent]::
> Git doesn't track directories, so doesn't need this command.  Simply
> adding content that is in a subdirectory is sufficient.
> 
> Git wins.   It does the right thing for you and you needn't remember to
> wrap your "mkdir"s with your VCS.  Also, one-less-command.

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
all object files in a single directory which the build system
creates, as cleaning up is just "rm -rf output" (or whatever it is)
so I could care less about empty directory tracking; I think most
people are that way.
 
>  - svn cat: the git equivalent is too complicated.
>    It wouldn't be hard to write a git-cat; if git's aliases allowed
>    pipes, it could be done instantly.

See above.

>  - svn list: this only wins because the default output of git-ls-tree is
>    so user unfriendly.

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

>  - 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
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.
 
>    As to git-repack and git-fsck-objects - when _should_ these be run?
>    How is the user meant to know?

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.

--