Re: svn versus git

> svn checkout::
> Checkout a working copy from a repository.  You may check out an
> arbitrary revision.
> git clone::
> git checkout::
> Git, of course, is different from subversion, as the whole repository is
> always available.  git-checkout is nearest in concept to svn-checkout
> though.  It changes the current working directory to a particular
> branch.  You may not checkout an arbitrary revision.  git-clone might
> also be considered as an svn checkout analog.  However,
>
> Subversion wins.  The output from Subversion's checkout is clear.  The
> output from git-clone gives output that is only understandable by
> someone familiar with git internals.

> svn commit::
> Pushes changes to the upstream respository from your working copy.
> git commit -a::
> Saves changes to the working copy as a new revision in the local
> repository.
>
> The need for "-a" (or not) because of git's staging area (the index)
> here makes it more confusing than svn-commit for new users.  However,
> the ability to do "git --amend" more than makes up for it.  Fixing a
> typo in your last log message is difficult in subversion.  Also, git's
> commit message template is much better: both uses the output of their
> status commands which is far clearer in git than in Subversion.
>
> Git wins.

> svn copy::
> Duplicate something in working copy or repository, remembering history.
> cp A B; git add B::
> Git doesn't have a direct equivalent of svn copy.  It's arguable whether
> it needs it once the user knows they can git-add so easily.
>
> Git wins.  Git's ability to detect copies after-the-fact, mean that a
> git-copy isn't necessary.

> svn move::
> Move and/or rename something in working copy or repository.
> git-mv::
> Move or rename a file, directory or symlink.
>
> Git wins.  The two are equivalent except that git can do multiple moves
> in one command, just like normal "mv".  So "git mv src/* newsrc/" works
> while "svn mv src/* newsrc/" doesn't.  Additionally, if you forget to do
> moves with git and instead use the command line, you can easily use
> "update-index" to tell git about the move after the fact.  In subversion
> you have to undo all the moves and do them again with subversion.  This
> makes it inconvenient to use tools like "rename" to do regexp moves.

> svn switch::
> Update the working copy to a different URL.
> [no git equivalent]::
> git is distributed and can fetch from any number of remote repositories.
> The URL can be typed on the command line of git-fetch, or can be given a
> shortcut as a "remote".  If we're talking about a single repository
> (which we have to to compare against subversion), the repository is
> local anyway.
>
> Git wins.  Command is unnecessary.

>  - svn revert: it's not easy to revert a single file in git; especially
>    once we bring the index into play.  Restoring a single file in the index
>    to HEAD while leaving the rest of the index AND the working directory
>    untouched requires something like
>    ----------------------------------------------------
>    git-ls-tree file | git-update-index --index-info
>    ----------------------------------------------------
>    Which isn't simple enough for a typical user.