Andy Parkins <andyparkins@xxxxxxxxx> 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. -- Shawn. - 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