Re: svn versus git

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 13, 2006, 22:56 UTC
Message-ID: <20061213225627.GC32568@spearce.org>
In-Reply-To: <200612132200.41420.andyparkins@gmail.com>

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?

Show 7 quoted lines

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

Show 9 quoted lines

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

Show 5 quoted lines

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

Show 8 quoted lines

> 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?

Show 6 quoted lines

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