git is so overly complex (Coming from svn).
* 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.
I can totally see git is ridiculously powerful, and general purpose. I just wish it'd default to what most people want a bit more.
Why do I get prompted to enter a commit message when I'm just doing a git pull?
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?
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.
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...
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`.
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)