Both Martinho Fernandes and tialaramex answers correctly describe what you need to do. Let me describe why it is the way it is.
Subversion
Subversion is centralized version control system. It means that it operates in client--server fashion: server stores all the data about version (repository), client has only working directory (files) plus some administrative and helper data. This means that for most commands client has to contact server. This also means that there are many commands asking about state of repository on server, or server configuration, like "svn status --show-updates
" in question.
(Sidenote: one helper data that Subversion stores on client are the "pristine" version of files, which means that checking for changes you did doesn't require to connect to server (which is slow)... but it also means that SVN checkout might be larger than Git repository).
"svn update" (required before commit if repository has any changes in given branch) downloads last version from remote and merges (tries to merge) changes you did with changes from remote. IMHO this update-before-commit workflow is not very conductive.
Git
Git is distributed version control system. This means that it operates on peer-to-peer fashion: each "client" has all the data about versions (full repository). The central repository is central only because of social convention and not technical limitations. This means that when contacting other remote repository the number of commands "executed remotely" is very small. You can ask for references (heads aka. branches and tags) with "git ls-remote" (and "git update show"), you can pull (get) or push (publish) data with "git fetch" (or "git remote update") / "git push", and if server is configured to allow it you can get snapshot of state of remote repository with "git archive --remote".
So to examine commits which are in remote repository but are not present in your repository you have to download data to your machine. But "git pull" is in fact nothing more than "git fetch" which downloads data and "git merge" which merges it (with a bit of sugar to prepare commit messages and choose which branch to merge). You can then use 'git fetch" (or "git remote update"), examine newly brought commits with "git log" and "gitk" (not being limited to fixed output), and then if everything is all right merge changes with "git merge".
This is not specific to Git, but to all distributed version control systems, although the way SCM presents fetched but unmerged data might differ (Git uses remote-tracking branches in 'remote/<remotename>/*' namespace, Mercurial from what I understand, uses unnamed heads).
HTH