git equivalent of svn status -u

Question

What's the git equivalent of svn status -u or more verbose svn status --show-updates. The svn status --show-updates command shows the updates that the svn update command will bring from the server.

Thanks!

Answer 1

I feel that my answer is too simplistic, but I always just use "git status" to see what is modified, what is going to be committed, what isn't, etc.

Answer 2

If you fetch:

git fetch <remote>

instead of pulling:

git pull <remote>

from the remote, you can then inspect what changed with git log. To apply the changes:

git merge <remote>/<remote-branch>

Answer 3

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.

Answer 4

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 command 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 of helper data that Subversion stores on client are "pristine" version of files, which means that checking for changes you did doean't need to connect 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 witch 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 perr-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 chose 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