git equivalent of svn status -u

Solution 1:

I can't think of a way to do it without actually fetching the updates (maybe someone else will). Assuming you are on the default branch "master" and the upstream from which these hypothetical updates will come is the default remote "origin", try....

git fetch
git log --name-only ..origin/master

Note the double dots .. not a single dot or an elipsis¹.

This will give you a list of log entries for changes that are only upstream, with the filenames affected, you can alter the parameters to git log to get more or less information.

NB in git "fetching" these updates isn't the same as applying them to your local branch. You no doubt already know how to do that with git pull.

¹ As for where do the double dots come from, name1..name2 indicates a range. If name1 is omitted, HEAD is used in its place. This syntax refers to all commits reachable from name2 back to, but not including, HEAD. ["Git from the bottom up"]

Solution 2:

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