subversion - svn tag vs git tag
git equivalent of svn status-u (5)
What's the git equivalent of
svn status -u or more verbose
svn status --show-updates.
svn status --show-updates command shows the updates that the
svn update command will bring from the server.
git fetch && git log --name-status ..origin/master does indeed show the logs that would be merged. However, it also pulls the changes. It's not technically possible to do the same exact thing as
svn status -u, but
git fetch is so fast that usually it shouldn't matter
If you absolutely need the log before fetching, the only way would be to connect (SSH or equivalent) into the remote and issue
git log there.
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 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).
Gits gives us more tools to check an "update". First you have to "download" the up-to-date state of the repository:
Now you can get the list of the changed files:
git log --name-status ..origin/master
Additionaly, you can see the full list of changes with diff:
git diff ..origin/master
Meaning of the starting letters are: Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B)
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 elipsis1.
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.
1 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"]
You can use
git ls-remote to list the SHA of references in a remote repository; so, you can see if there are any changes by comparing the output of:
$ git show-ref origin/master # <-- Where this repo thinks "origin/master" is 5bad423ae8d9055d989a66598d3c4473dbe97f8f refs/remotes/origin/master $ git ls-remote origin master # <-- Where "origin" thinks "master" is 060bbe2125ec5e236a6c6eaed2e715b0328a9106 refs/heads/master
If they differ, then there are changes to fetch:
$ git remote update Fetching origin ... From github.com:xxxx/yyyy 5bad423..060bbe2 master -> origin/master