How can I check the status of a remote Git repository?

Question

I have a remote Git repository to which I can push/pull from a local repository via SSH.

I can use the Git status command to check the untracked/unstaged files in the local repository. How do I do the same with the remote repository?

Please note that I'm not looking at finding the differences between the local commit and the remote commit.

Answer 1

This may not be exactly what you are looking for but I got here asking a similar question of Google. What I wanted to know is "where is my remote currently at in relation to my local master.

 git log

was what I needed.

commit 7bf74892162713b87a19c6194c8041c9bbf96552 (HEAD -> master, origin/master)
Author: Andy Reilly <andy@blah.com>
Date:   Tue Nov 9 18:46:16 2021 -0800

fixed data validation lock on condition column in upload spreadsheet

commit 8462456d5fe6bcc11acbf89bca949f15faef0424 (training-db/master)
Author: Andy Reilly <andy@blah.com>
Date:   Mon Nov 8 12:28:02 2021 -0800

added todo for future setup

commit 1cf4a93d419c4ccc1d1f5ac9203edd2b9cefafa4
Author: Andy Reilly <andy@blah.com>
Date:   Mon Nov 8 11:15:56 2021 -0800

added uniqueness to tenant for category names so accidental rerun of initial setup does not create duplicates

commit 28f2d5a2c4ca869ebdb086696c97554587592e27 (multi-tenant/master)
Author: Andy Reilly <andy@blah.com>
Date:   Sat Nov 6 18:32:09 2021 -0700

So know I knew that my training server was one commit behind and my production server was two commits behind.

Answer 2

git fetch --dry-run --verbose may show what you need.

Example:

# Before a remote update:
user@localhost:~/build/demo/myrepo$ git fetch --dry-run --verbose
From https://gitserver.local/git/myrepo
 = [up to date]      master     -> origin/master

# After a remote update:
user@localhost:~/build/demo/myrepo$ git fetch --dry-run --verbose
POST git-upload-pack (328 bytes)
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 8 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
From https://gitserver.local/git/myrepo
   83619a7..67ea28b  master     -> origin/master

Caveats:

• The exit code does not reflect your local repository being in sync with the remote repository; it only reflects on the action itself being successful or not.
• If your local repository contains newer changes than the remote repository, Git fetch still considers your local repository up to date. Maybe git push --dry-run helps for this case.

Answer 3

If you have a Git remote repository, to which you can git push via SSH, it should generally¹ be a --bare repository (see the description of setting up a bare repository on a server in the on-line Git book). A bare repository doesn't have any place in which to do any work on it. This means git status has nothing to report—in fact, if you have a bare repository and cd to it, you get an error message: it needs a work directory in order to report anything.)

The technical definition of a bare repository is one in which git config --get --bool core.bare prints true. I have a non-bare repository in /tmp/t to start, here:

$ cd /tmp/t; git config --get --bool core.bare
false
$ cd /tmp; git clone --bare t bare.t.git
Cloning into bare repository 'bare.t.git'...
done.
$ cd bare.t.git
$ git config --get --bool core.bare
true

But it's usually obvious from inspection: if your clone says that the origin is ssh://some.host/some/dir/repo, and you can ssh some.host and cd /some/dir/repo and ls, a "bare" clone looks much like the contents of the .git directory on the non-bare clone:

$ cd /tmp/t; ls .git
COMMIT_EDITMSG  ORIG_HEAD       description     index           objects
FETCH_HEAD      branches        gitk.cache      info            packed-refs
HEAD            config          hooks           logs            refs

vs:

$ cd /tmp/bare.t.git; ls
HEAD            config          hooks           objects         refs
branches        description     info            packed-refs

(The bare clone lacks a few of the files made doing ordinary Git work in the non-bare one, but they are clearly related.)

---

¹It's possible to push to non-bare repositories—it's just a bad idea. If you look at your own non-bare clone's .git/config (or use the more official interface, git config --get receive.denyCurrentBranch), you will generally see something like this:

[receive]
        denyCurrentBranch = warn

The value here may be any of refuse, true, warn, false, or ignore. Most values set things up so that push is only accepted if the push is to some branch other than the "current" branch.

The problem here is ... well, suppose you're logged in on the server to which other people push. And lo and behold, you cd /some/dir/repo and there are all these work files.

It's quite tempting to git checkout zorg, edit the number of taxi drivers, and git commit the result. But what happens when someone else is editing the same branch elsewhere, and commits and then git push-es in the middle of you doing something similar?

If he/she finishes his/her push before you start your commit, you have kind of a mess. Normally, both of you do this on systems other than the server, and whoever pushes first "wins" and the other person gets a failed "non fast forward" push and knows to fetch-and-(merge-or-rebase) (git pull or git pull --rebase or whatever).

But you're already on the server, so you can't use the normal work flow. In fact, it's tough to keep the work tree up-to-date in the first place: you can do this with a hook, but if you have the hook git reset --hard to update the work tree, it throws away any work anyone was doing.²

It's easier to just avoid the problem entirely: decree that there is no work tree, and that this is to be a --bare clone. All the temptations and problems vanish.

²At one job, I inherited a setup that did just that (git reset --hard in a post-receive hook, and also at six-hour intervals via cron). It caused a lot of confusion at least once every few months. Unfortunately, the server and directory paths were hard-wired lots of places, making it hard to fix, too (and this particular issue was low priority). We just lived with it.

_{(As requested in comments, this is the two comments in "answer" form. I've expanded them a bit since there is more space here.)}