Git, in my opinion, now has (multiple) UI wrappers that are far more intuitive than TortiseSVN has ever bin. And yes, there is TortiseGit, although SmartGit is much better.

Give SmartGit a try – I think you’ll realize Git is much easier to teach than SVN, especially to somehow who hasn’t used either before.

Every SVN user I’ve introduced to Git has switched and never gone back.

But if you just want to revert local changes, not undo changes from an existing commit, you may want to do a checkout, not a reset. I admit this terminology sounds weird coming from svn, but once you start thinking of your .git folder as its own repository, it makes sense. git revert is like svn reverse-merge.

I tried your git reset -- file but it didn’t work for me.

git rm RobotRunner.php
git status
 deleted: RobotRunner.php
git reset -- RobotRunner.php
 src/lib/Strings.php: needs update

I think by “needs update” it means I need to do a “commit” of some other unrelated files, right? (The naming is not necessarily wrong, but for sure confusing for CVS/Subversion users!). Well I don’t want to do a commit, I just want to do something similar to svn revert.

Whether svn revert file is simplier than git reset -- file is I think the matter of taste. git-revert is taken to mean create a commit which reverts changes in given commit (cherry-picking reverse of commit, patch -R…).

You can do a quick fix on the live server and commit – That doesn’t work for me. In the following example, I alter a file, check it in locally. This file is up-to-date even though the checkout isn’t up-to-date as a whole. After a pull the file has not been altered (showing that it was up-to-date). But only after the pull (updating other files I don’t want to change) can I do a push.

vi Wizard.class.php
git commit Wizard.class.php
md5sum Wizard.class.php
  a3472e35266331b664e547feedfd459a  Wizard.class.php
git push
  ! [rejected]        master -> master (non-fast forward)
git pull
md5sum Wizard.class.php
  a3472e35266331b664e547feedfd459a  Wizard.class.php
git push
  fc1b1d7..5edbc69  master -> master

Other points about Git’s usage – Thanks for the tips.

I think as a system increases in complexity, the number of clicks or options one needs to achieve a given task necessarily increases. For example in Google Spreadsheets (simple) there is a “formatting” drop-down where I can select the 0.00 format. On Excel I have to right-click, select formatting, select “number”, then choose the number of decimal places. I think because Subversion is simpler, those things which are also possible with Git, are more accessible in Subversion: for example “svn revert xxx.txt” is easier than the 3 methods you described. Easier means a larger set of people will use the feature, meaning the tool as a whole becomes more useful, as there is less emailing of files. Of course it comes at the trade-off of other features not being available at all, however if they’re not needed (depends on what you’re doing) then that’s a good trade-off.

Reverting your changes to some file?: Supposed ‘Git expert’ wasn’t much of an expert if he/she didn’t know about git checkout -- <file>, git checkout HEAD -- <file> or (in newer Git) git reset -- <file>. Unfortunately (for Subversion users) ‘revert’ means something different in Git than in Subversion… you can always make ‘revert-file’ alias.

Binary files are automatically detected in Git (and you can use gitattributes to override detection based on pathnames). The title is “Why Subversion is better than Git” not “better than CVS”, isn’t it?

Executable flag (executable bit) is supported in Git. Symbolic links are also supported.

Ignoring files: I disagree, properties are worse solution than ‘.gitignore’ file(s) (and ‘.git/info/exclude’, and core.excludesFile). First, they are not recursive. Second (correct me if I am wrong) cvs:ignore is client property, so it cannot be propagated (like tracked .gitignore file can).

Want to commit with a different user?: ‘git commit –author’. By the way, if you are applying patch with description from email using ‘git am’ authorship of a commit is set automagically.

Absolute paths should now work with (modern) Git. Well… I have checked that ‘git add /home/adrian/checkout/file.txt’ works.

The help is clear (example of ‘svn log’ and ‘git log’): more features (like e.g. –grep, or –author, or –since) means longer manpage. But I agree that Git manpages might be cleaner and more newbie friendly.

You can do a quick fix on the live server and commit it WTF? You can do a commit in Git keeping some files in working directiries dirty, never mind not updated… Perhaps I don’t understand this issue…

Subversion repositories are URLs So are Git (well, that, or scp-like expressions). And you can put HTTP ones in browser (although you won’t see much if repository is bare, i.e. without working area, as it should be for public repositories, usually), and you can configure gitweb to share the same HTTP URL as repository. Access via SSH or anonymous git:// protocol is much faster; this might change in the future when “smart” HTTP server will get finished.

You can force locking. True, that is next to impossible in Git. Git is inherently distributed SCM. But I think one would be able to cobble something using hooks and locks / lock server… OTOH you can have custom merge drivers (configured using gitattributes) in Git.

You can embed expandable keywords: Git, because of its policy of not updating file in working directory if its contents didn’t change, support only very limited set of keywords out of the box, and they have to be turned on using ‘ident’ and ‘export-subst’ gitattributes… or you can use set of smudge / clean checkout gitatribute filters.

You can checkout only a subdirectory of repository: currently it is not possible in Git, but patches for ‘partial checkout’ are floating on git mailing list.

Old servers can talk to new clients and vice-versa. With Git too.

Output is copy-paste friendly (where you mean that ‘svn diff’ doesn’t have prefix in filenames, i.e. it is “patch -p0″ compatibile patch). For Git it was more important to be compatibile with commonly used “patch -p1″, but if you really need it there is ‘–no-prefix’ option to git-diff.

Subversion can handle Unicode file names. Well, it depends on what do you understand by this, but Git does also support international characters in filenames.

SVN Externals are cool. Git submodules are svn:externals done right :-)

Git really is unbelievably fast. But is that actually a useful feature? If diff or status, or commit on the whole project takes seconds or minutes rather than fraction of second, it does matter, because it changes workflow.

‘svn log’ on a directory can yield somewhat confusing results if your directory isn’t up-to-date, but yes, it does show changes to files inside the directory, exactly as ‘svn log URL’ does.

We, Subversion, are working on re-writing the way the “working copy” is managed for the 1.7 release (this summer). It will get all those .svn folders out of the working copy which should solve the grep issue and it will also bring massive performance improvements by eliminating all of the crawling of the working copy that has to happen today.

The upcoming 1.6 release brings some improvements to rename handling. Specifically, adding the concept of a “tree conflict”. So for example, if you rename a file and then run update, and the update brought in changes to the renamed file, this would raise a tree conflict so that you could review those changes and incorporate them into the renamed version. Today, in 1.5, this whole process if very silent and you could easily miss the situation.

Anyway, thanks for the posting.

Mark

@Stripes – Thanks for the tip.

@Helge – I’m not sure, but certainly at the start CVS was used by nobody, not even web designers. I had to fight hard to get CVS adopted by web design and even so certain things like branches always caused problems to the less technically minded staff. You certainly refused to use it at the start, but that may have changed as time went on. But I understand your rejecting of it – WinCVS was a nightmare – the tool was at fault here – the tool should fit the people (be easy enough to use so as to be accepted by them) not the other way around.

@Flo – Git revert – That’s what my git expert said too, until he tried it. But maybe it’s easier than it seemed at the time, once you know how.

Files can be ignored – Yes you’re right about the recursive feature. I’ve never needed them to be recursive but I can imagine there are plenty of situations where you do.

“git log” usability – True but can you name me the way to get the log to follow file moves/copies? It’s buryed many pages down on the documentation, and there are many options described similar. For example “-M Detect rename” (that’s the entire docu) is not the option I was looking for. SVN has this on by default. I think one of the reasons the SVN docu is smaller is because it does the right thing by default, but maybe I’m wrong.

“svn log” pager – True.

Library – True, but it’s still a collection of command-line tools like CVS. I don’t think that’s the right way to write software, as the only way to interact with command-line tools are arguments and lines of result. To interact with a library you need richer parameters and return values, i.e. objects and structures, which can contain other objects and structures.

Speed – But “svn diff” and “svn log” are also fast. This repository (28k commits): “svn diff” on a file took 0.01 seconds. “svn log” took 0.9 seconds. True if you do it on a directory it takes longer. On the entire checkout (12k regular files) a svn diff took 1.3s (but this wasn’t the first time I ran it – probably everything was in FS cache), and there were very few changes).

Comparison to CVS – True, that deviated from the title a bit.

Tortoise Git – That’s good to hear. I’m sure many of these usability issues will go away with time (the ones that are just down to bad docu and bad defaults.). I mean Tortoise CVS basically hid most of the CVS options. (e.g. “yes I want recursive!”).

But there is still the feeling at the back of my mind that Git solves a problem I don’t need solving, and in doing so, necessarily alienates a lot of users who not only don’t need those problems solving, but also aren’t going to take the time, or may lack the education necessary, to understand the solutions to them.