git-log --name-status

I've been using git for the past month (I just realized that today was my first whole month at work) and I'm very happy with it. I'm used to svn (and before that, CVS) and I'd gotten around the ugly (so much so that I never used the version discussed in the subversion book for versions below 1.5) merging in svn by using svnmerge (which, while not making merging painless, did make it sufficiently less painful that it was actually usable).

For a long time I looked at git but never actually dived in head first since casual acquaintance with git made me feel dumb. Now that I've been using it for a month though (well, with git-svn, since my current project uses svn), I'm getting used to it, I've got the basic workflow down and I'm slowly learning more advanced workflows.

For a long time too I didn't like git because I thought it didn't have an equivalent to "svn log -v", that is, show the revision number, author, message, and the affected files. git-log showed the first three, but not the last. I was probably looking at an early version of git though, this would have been in 2006 or so. Sometime in revision 1.4, git-log got --name-status, but I didn't notice. Anyway, it required -r if you wanted to see recursive changes. 1.5 has better behavior now. --name-status shows filenames and what was done to them (deleted, added, modified, etc), and the -r is implied.

There are still some things I'm not clear on (e.g., how to do the equivalent of svn:externals, which is probably a SMORTD, a simple matter of reading the documentation). But given that the main VCS at work is SVN, how to work with svn:externals with git and git-svn :-).

I'll get there though. Although it may take a while since, in fact, we don't use svn:externals or similar in our current projects (in fact, the reason I decided to use git and git-svn was because we don't have the regular trunk and branches structure either, and being the new guy, I didn't want to be creating a test branch for myself at the root of the svn tree :-).

In any case, git-reset and friends (i haven't tried the --interactive options to git-commit or git-rebase and friends yet, but I will, one of these days) are great helps and because of their (admittedly, simple) enhancements to my workflow, I'm not going to be switching back to pure svn.

Our project isn't so large that the git vs svn speed difference is a factor, but I have (at a previous job) worked with sufficiently large trees and branches that the speed of git would have been a huge help. On the other hand, as smart as my co-workers were, at that job, I think that pushing git into the organization would have been too big a challenge in the time I had. svn was certainly the better choice there (since svnmerge was available, before I learned svnmerge, I spent far too much time hand-merging between branches).