Re: svn versus git

[Jakub Narebski <jnareb@gmail.com>]

By the way, it would be nice to have this discussion added to GitWiki:
  http://git.or.cz/gitwiki/GitSvnComparsion

Andy Parkins 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)::
> git-ls-tree lists the object ID for $file in revision $REV, this is cut
> out of the output and used as an argument to git-cat-file, which should
> really be called git-cat-object, and simply dumps that object to stdout.

You can use extended sha1 syntax, described in git-rev-parse(1) (although
it would be nice to have relevant parts of documentation repeated in
git-cat-file(1)), namely
  git cat-file -p REV:file
(and you can use "git cat-file -p ::file" to get index/staging area
version)
 
As for alias: what about "alias.less = --paginate cat-file -p",
set using "git repo-config alias.less '--paginate cat-file -p'"?
 
> svn cleanup::
> Recursively clean up the working copy, removing locks, resuming
> unfinished operations, etc.
> git fsck-objects::
> git prune::
> git repack::
> Check the repository for consistency, remove unreferenced objects, or
> recompress existing objects.
> 
> They don't really serve the exact same purpose, but they are all
> maintenance commands.
> 
> Subversion wins, as it only has one command and you don't need to
> understand the repository in order to understand what its doing.

git-fsck-objects is needed only if something doesn't work when
it should. "git repack" is safe, "git repack -a -d" is almost safe,
while "git prune" is not.
 
> svn export::
> Create an unversioned copy of a tree.
> git archive::
> Creates an archive of the files in the named tree.
> 
> Git wins.  It can make zip/tar directly and add directory prefixes
> should you want them.  It could perhaps be a modicum easier if it had a
> default output format so that "git-archive HEAD" would do something.

Perhaps git-archive should support "tree" format, i.e. writing
unversioned copy of a tree to filesystem.
 
> svn resolved::
> Remove 'conflicted' state on working copy files or directories.
> git update-index::
> git checkout::
> Git doesn't have a direct "resolved"; after you fix conflicts, you push
> the changes into the staging area with "git-update-index".
> Alternatively you can simply accept the version in HEAD by checking out
> that version.
> 
> Draw.  "svn-resolved" is rubbish, as it doesn't do any checks, it just
> removes the conflict markers.  Git could do with something that makes
> life easier than understanding the index.

There was discussion about adding thin wrapper around git-update-index
to specifically mark resolved merge conflicts. The option to pick up
ours, theirs, ancestor version is another argument for having such command.
 
> svn revert::
> Restore pristine working copy file (undo most local edits).
> git reset --hard::
> Reset the repository to an arbitrary point in the past, updating the
> working copy as well.
> git checkout -f HEAD <file>::
> Checks out <file> from HEAD, forcing an overwrite of any working
> directory changes to that file.
> 
> Draw.  There is no easy way to undo changes that have already been
> committed to a subversion repository, so git would win.  However, it's
> uncomfortable to revert a single file using checkout.

There was talk about adding "git reset [<commit-ish>] -- <file>".

> Discussion
> ----------
> 
> What would git need to do to win in every section?
> 
> Subversion won:
>  - 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.

It can be done without pipes: "git cat-file -p REV:file".
You can use aliases to have shorter name for that.

>  - svn checkout: the output from git-clone is unfriendly.
>    -------------------
>    remote: Generating pack...
>    remote: Done counting 6 objects.
>    remote: Deltifying 6 objects.
>    remote:  100% (6/6) done
>    Indexing 6 objects.
>    remote: Total 6, written 6 (delta 0), reused 0 (delta 0)
>     100% (6/6) done
>    -------------------
>    What are "objects"?  What is deltifying?  Why does object count
>    matter to me?  What is indexing?  How much data was transferred?  How
>    long did it take?  How big is my local clone?
>    
>    While transferring: how long is it going to take to finish?  How much
>    data is there to transfer in total?

Hmmm... I thought that some progress indicator of download/upload was
added... guess I was wrong.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git