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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html