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.

git has a very steep learning curve. i think that is the very most important
argument, why it’s not suitable for non-technichal staff (like designers).

i couldn’t resist commenting on some of the comparisons you listed :)

> Directories being empty
$ touch path/to/empy/subdir/.gitignore
should do it. not the most elegant way, though.

> Want to revert your changes?
> I have watched a “Git expert” spend 30 …
you saw me reverting changes it in seconds :)

> Files can be ignored
i don’t think SVNs Ignore scheme is good.
first of all, it is hidden deep in some obscure svn properties (which names i cannot remember due to seldom usage), instead of a simple
plaintext file (.gitignore).

further, the last time i used SVN’s ignore feature, i coudln’t find a way to
define recursive ignore patterns.
now thats ugly. do i really have to create a ignore-property for VI .swp files
for every subdir?

with git you have a single .gitignore in the project root. single point of
configuraion (in my opinion the best way to handle this kind of issue)
and it can handle global patterns (*.swp), directories (log/)
and single files (src/lib/foo.bar).

> history in git (was help is clear)
since git is very complex and can do lots of stuff, the help is very elaborate. this is
not very usable, indeed. (learning curve argument)
or better: it’s not beginner-friendly. but it is definitely expert-friendly.

working with git’s log features has often helped me finding stuff
faster. on the other hand, i really don’t unterstand why ’svn log’ doesn’t
automatically pipe to a pager. i think the cases where you would read the log
output in a pager outnumbers the others by far.

> You can force locking
afaik, not being able to LOCK is a feature of DVCS, not a bug and not
git-specific.
i might be wrong on this one.

> Output is copy-paste friendly
> .. extra “a/” in front of the name ..
i agree. that sucks. has bogged me several times, too.

> Internally, Subversion separate logic from UI
git also strongly divided lowlevel (“plumbing”) and highlevel (“porcelain”) tools.
git-pull, for example, is a shell script.

> Git really is unbelievably fast.
> But it only do “svn up” once a day”
that’s right. i do ‘git log’ and ‘git diff’ pretty regulary. especially
for a diff it’s great when you have all the information locally instead
of having to talk to the server for it.

> git error messages
i totally agree. git’s error messages are often misleading and/or only understandable by
people who know the internals of git.

At some points you say svn is better, because it can do things,
_CVS_ couldn’t do. (but git can do; sometimes even better).
These would be (svn & git) > cvs reasons.

btw there’s a TortoiseGit in development. (http://code.google.com/p/tortoisegit/ ).

best wishes,
flo

Dodge, you need to be using ack, sir.