Does "git status" actually check whether upstream repo matches my repo?

Question

It doesn't look like

git status

actually checks whether my commits on github for example are fully in sync with my local state. Which isn't surprising because of the performance issues. How do I force a true check?

Answer 1

How do I force a true check?

git fetch

Which isn't surprising because of the performance issues.

Actually, even a local check (after a git fetch) can sometime be too costly:
"git status" can spend a lot of cycles to compute the relation between the current branch and its upstream, which can now be disabled with "--no-ahead-behind" option.

See commit f39a757, commit 3ca1897, commit fd9b544, commit d7d1b49 (09 Jan 2018) by Jeff Hostetler (jeffhostetler).
^{(Merged by Junio C Hamano -- gitster -- in commit 4094e47, 08 Mar 2018)}

status: add --[no-]ahead-behind to status and commit for V2 format.

Teach "git status" and "git commit" to accept "--no-ahead-behind" and "--ahead-behind" arguments to request quick or full ahead/behind reporting.

When "--no-ahead-behind" is given, the existing porcelain V2 line "branch.ab +x -y" is replaced with a new "branch.ab +? -?" line.
This indicates that the branch and its upstream are or are not equal without the expense of computing the full ahead/behind values.

status: support --no-ahead-behind in long format

Teach long (normal) status format to respect the --no-ahead-behind parameter and skip the possibly expensive ahead/behind computation between the branch and the upstream.

Teach "git status --short --branch" to respect "--no-ahead-behind" parameter to skip computing ahead/behind counts for the branch and its upstream and just report '[different]'.

---

Git 2.23 (Q3 2019) adds a new feature: "git status" can be told a non-standard default value for the "--[no-]ahead-behind" option with a new configuration variable status.aheadBehind.

See commit fb4db1a, commit 0a53561, commit 06b324c (18 Jun 2019) by Jeff Hostetler (jeffhostetler).
^{(Merged by Junio C Hamano -- gitster -- in commit 3418622, 09 Jul 2019)}

status: add status.aheadbehind setting

The --[no-]ahead-behind option was introduced in fd9b544 (status: add --[no-]ahead-behind to status and commit for V2 format, 2018-01-09, Git v2.17.0-rc0).
This is a necessary change of behavior in repos where the remote tracking branches can move very quickly ahead of the local branches.
However, users need to remember to provide the command-line argument every time.

Add a new "status.aheadBehind" config setting to change the default behavior of all git status formats.

The git status documentation now includes:

status.aheadBehind:

Set to true to enable --ahead-behind and false to enable --no-ahead-behind by default in git-status for non-porcelain status formats.
Defaults to true.

And:

status: warn when a/b calculation takes too long

The ahead/behind calculation in 'git status' can be slow in some cases.
Users may not realize that there are ways to avoid this computation, especially if they are not using the information.

Add a warning that appears if this calculation takes more than two seconds.
The warning can be disabled through the new config setting advice.statusAheadBehind.

That means the git config advice documentation now has:

statusAheadBehind:

Shown when git-status computes the ahead/behind counts for a local ref compared to its remote tracking ref, and that calculation takes longer than expected.
Will not appear if status.aheadBehind is false or the option --no-ahead-behind is given.

Answer 2

Do git fetch and then git status so that the check of your (for en example) master with origin/master (both of which are local on your machine) will give you what you want - that is comapre master to the state on upstream remote repository.

Answer 3

That’s not the intent behind git status. You need to use git diff instead:

git diff <your (master?) path> <remote path>

This comes up a lot. For example: git diff between remote and local repo

Answer 4

You need to do a fetch first. This will update your local repo to match the remote.

git fetch origin
git status

Fetch will not change your working directory, like git pull does.

Answer 5

Short answer: No it does not.

It compares your current working directory to your local HEAD commit.

From the documentation:

Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the working tree and the index file, and paths in the working tree that are not tracked by Git (and are not ignored by gitignore[5]).

https://git-scm.com/docs/git-status