understanding git fetch then merge

Coming from an svn background, I had this question:

https://stackoverflow.com/questions/1138990/git-equivalent-of-svn-status-u

(what is the git equivalent of svn status -u)

And I understand, you do:

git fetch
git log ..origin/master

But, I'm guessing the origin/master part depends on the branch? It wouldn't necessarily be master if I was tracking a remote branch?

I also don't understand the git merge origin/master precisely. I'm guessing that just means that git fetch grabbed the changes from the remote and put them into the git database system as origin/master and I'm in just master? What if I fetched changes, check what was done, am horrified by the changes and don't want to merge? How do I basically abandon them?

git fetch

git fetch grabs changes from remote repository and puts it in your repository's object database. It also fetches branches from remote repository and stores them as remote-tracking branches.

When you are fetching git tells you where it stores each branch on remote repository it fetches. For example you should see something like

   7987baa..2086e7b  master -> origin/master

when fetching. This means that 'origin/master' stores where 'master' is on 'origin' repository.

If you examine .git/config file, you would see the following fragment:

[remote "origin"]
url = git://git.example.com/repo.git
fetch = +refs/heads/:refs/remotes/origin/

This (among others) means that any branch 'A' ('refs/heads/A') in origin remote (repository you cloned from) would be saved as 'origin/A' ('refs/remotes/origin/A').

git log ..origin/master

As you can see 'origin/master' is 'master' in origin. If you are on (default) 'master' branch, then git log ..origin/master, which is equivalent to git log HEAD..origin/master, which when on 'master' branch is equivalent to git log master..origin/master would list all commits that are on 'master' branch in remote repository and are not in local 'master' branch where you do your work.

The more generic version in modern git (assuming that upstream / tracking information exists) would be to use simply

$ git log ..@{u}

(Here @{u} is synonym for @{upstream}, see [gitrevisions][] manpage).

[gitrevisions]: http://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html "gitrevisions(7) Manual Page - specifying revisions and ranges for git"

git merge origin/master

git merge is used to join two lines of history. If one of sides didn't do any work since last branching point (since merge base), the situation is either fast-forward (the branch you are on is simply updated to the tip of the branch you are merging), or up-to-date (there is nothing new to merge, and the branch you are on stays unchanged).

git fetch followed by git merge origin/master, when on 'master' branch, is equivalent to issuing

$ git pull

---

If you don't want to merge, you don't need to. Note that you can use e.g. git reset --hard HEAD@{1} to go back and discard result of git pull if you don't like it.

git fetch downloads all the changes needed to represent the given remote branch. Typically this is origin/master or similar.

git merge merges two branches together by creating new commits or fast-forwarding (or a combination). It doesn't change any commits you have made, and you can always roll back to your old branch (using git reset or git checkout).

Note that git pull is git fetch followed by git merge (or git rebase if --rebase is given).