I think that for people with an svn background there are three different issues that all hit at once:
* distributed rather than centralised version control brings a new set of concepts to understand
* git is flexible enough to support many different workflows. This means you have to actually choose one, and choice is difficult especially when you're just trying to get to grips with a new tool. svn has much more of a "one standard way to do it" approach
* git's UI is in places confusing, inconsistent and occasionally just randomly and unnecessarily different from most other version control systems
The first two are 'essential complexity'; the third is more 'accidental complexity'. In any case I feel it's having to deal with all three sources of confusion that makes the svn->git transition tricky for many people.
"Distributed" is not the same as "ad hoc". In virtually all workflows, whether using distributed or centralized RCS, there will be a master copy. The difference between distributed and centralized is whether that master copy is the only copy.
In my experience, git is more complex than svn, but not needlessly so. In any sufficiently long-running project, I've wanted features that git has and svn doesn't.
Why do I get prompted to enter a commit message when I'm just doing a git pull?
Because `git pull` == `git fetch` + `git merge`. If there are upstream commits you are fetching that are not ancestors of your head commit, then pulling involves merging the divergent history, thus creating a new merge commit. And a merge commit, like any commit, needs a message.
Why do I have to explicitly add every file I want to commit each time?
Because Git has an intermediate staging area (the "index") between your working directory and the committed history. This is a great feature; one of the most useful aspects of Git, in fact. The side effect is that you must add your changes to the index before committing, but this is a small price to pay for the huge increase in flexibility the index affords.
Why can't it just default to "everything under the current dir" like svn does?
You can do `git add .` to add everything in the current directory without naming it all explicitly. Or you can use the `git commit -a` shortcut (and similar -A and -u options) to add and commit in a single command. This is hardly a significant increase in effort over `svn commit`.
If you have commits in your local branch and you are doing a pull without --rebase you can get merge commits, but I believe those messages should be generated for you(?). I almost always choose rebase over merge so there are no merge commits, all my merges are fast forward. Check your workflow.
Regarding your second question, you want "git add -a". Git gives you the ability to commit "some of what I've changed here", even within files (see git add -i). This facilitates clean commit history by letting you control exactly what is in each commit (even if you changed other files).
And even once you've made your commits to your private branch of course you can continue to change the order of them or combine them with interactive rebase... until you push...
> Why do I get prompted to enter a commit message when I'm just doing a git pull?
This shouldn't happen; you need to rethink how you're set up.
> Why do I have to explicitly add every file I want to commit each time? Why can't it just default to "everything under the current dir" like svn does?
You can use git commit -a
Edit: by "rethink" I mean research why this is happening, because it isn't by design. I'm sure somebody can help, I just don't have the answer for you.
> Why do I get prompted to enter a commit message when I'm just doing a git pull?
Not sure. The only time this happens to me is when I need to fix a merge conflict.
> Why do I have to explicitly add every file I want to commit each time? Why can't it just default to "everything under the current dir" like svn does?
"git add ." adds everything below the current directory.
1.
`git pull` = fetch + merge
If the merge has conflicts, then you got to solve the conflicts and do the commit manually (entering the commit message)
If the merge doesn't have conflicts, then the merge commit is automatic.
2.
`git commit -m "foobar"` will commit the files from the stage/index
`git commit -am "foobar"` will commit all the modified files (it will ignore untracked files)
svn always seemed limited to me if your dev team grows beyond the capability of utilizing simple verbal communication to mitigate problems when merging.
Personally, I've never been a fan of branching and merging. I don't think it works well at all for small groups. Maybe if you're in a big corp. though.
