How to detect differences between a local repository and remote repository in Git

Question

Say I did a Git clone from a URL for a repository. I made some changes to a file, did a Git commit.

When I do a git pull, I see that it says "Already up-to-date".

Shouldn't it show something that says I am not up to date?

My question is:

1. say I did the change above to my local repository, but do not commit for two days, but before the two days are up, someone else had made a change to the remote repository. What steps must I do to ensure I am not overriding changes in the remote repository or at least be able to pull the latest changes before committing?

2. Is there some way to diff between my local repository and the remote repository to check what differences there are? (in case I just want to recall what I had before?)

Answer 1

My first advice is to not git pull. Do a git fetch followed by a git merge.

To answer your zero'th question: In fact, you are up-to-date. You have all the commits that the remote repository has. So, there is nothing left to fetch or merge¹.

To answer your first question:

1. git commit: commit your changes on your own branch, totally unrelated to what's going on in remote repositories.
2. git fetch origin: get the contents of the remote repository (origin), but keep them under origin/branch branches. Your own code is unaffected at this point.
3. git merge origin/master: merge origin/master which is the master branch of the remote repository origin (which you fetched just now) with your current branch.
4. git push origin: push back the commit and the merge to the remote repository

To answer your second question:

1. git fetch origin: update origin/branch branches.
2. git diff origin/master: get the difference between your current branch and the branch origin/master.

---

¹ Suppose this is what the commits in your repository initially look like, on branch master:

A -> B -> C -> D -> E
                    |
                    |\- master
                    |
                     \- origin/master

This is right after you cloned the repository. Now you say you have made a new commit on your local branch master:

A -> B -> C -> D -> E -> F
                    |    |
                    |     \- master
                    |
                     \- origin/master

So there are two things to observe here.

1. Assuming no activity by somebody else in the remote origin, there is nothing new to fetch. So git fetch origin master tells you there is nothing new.

2. If you do git merge origin/master, again, there is nothing to merge. origin/master is a prefix of master. In other words, master already contains all the commits that origin/master has, so there is nothing new to merge.

If you had used fetch and merge instead of pull, you could easily understand which part of the double-command (pull) is the one that results in unexpected (in your opinion) behavior.

Of course, after a git push origin master, you will get:

A -> B -> C -> D -> E -> F
                         |
                         |\- master
                         |
                          \- origin/master

Answer 2

When you pull, it pulls in the history from the server and automatically tries to merge anything you have changed, with things that other people have changed. If it can do it automatically, then it will succeed and you won't see anything, and if it fails then you will be asked to fix any conflicts. You will never be able to silently override changes that other people have made.

If you do want to see if someone has changed something, you can run this git fetch and then git status. Status will print out what files have changes locally, but it will also say something like "Your branch is 2 commits ahead of origin/master", meaning you have 2 commits that have not been pushed to the server. If someone else has pushed to the server too, then it will say something like "Your local branch and the origin/master have diverged. This means both you and someone else have committed to master, and when you pull it will try to merge them, as described above.