How can git status reflect changes made by other users in shared environment?

Question

The question of the subject relates to what gitguys.com seemS to claim in order to explain that "the output of git status should not change" in an environment of multiple users working off NON-NARE repository (http://www.gitguys.com/topics/shared-repositories-should-be-bare-repositories/)

Within the aforementioned webpage it is explained that if someone created " a non-bare git repository with both the git repository user and remote users updating the git object database. The creator of the non-bare git repository would use the git status command one minute and see this: $ git status

# On branch master

nothing to commit (working directory clean)

The next minute, a remote user could git push a change into the non-bare repository. Then when the creator of the non-bare git repository types git status, git would find a different object database and give different results for this run of git status." The tutorial concludes with the following assertion which I find hard to explain based on what I know: The output of git status should not change unless the user has changed files in the working directory or their object database!

I find this "hard to explain" because this statement is the rationale behind why bare repositories (as opposed to non-bare repositories) should be employed in central repository environment where multiple users share that repository. This statement does not seem to be correct for me and therefore makes it difficult to reason why bare repositories are required in multiple users development environment. It's not correct because it IMPLIES THAT GIT STATUS IS AFFECTED BY THE STATE OF THE SERVER REPOSITORY WHEREAS i THOUGHT/BELIEVED THAT git status takes into consideration only the LOCAL .git file objects and the working directory (i.e., not on the server)

Please note that I have been trying to reason why bare repositories are necessaries without just taking as a given that bare repositories are good for shared environment -- but so far I have not done so with much success (including in this website, perhaps because I did not pose the issue at hand properly; I hope this time I got it right as far as laying out the issue)

can someone explain how could it be that even when dealing with non-bare repositories with multiple users (assume 2 users: USER A and USER B), USER A, for example, might get 2 different results when issuing git status because of a change, followed with git push by USER B

Answer 1

It seems to me, although I could be wrong, that you have trouble understanding how a team can effectivly collaborate on a project via a remote repository.

I'll explain some basic concepts before starting to address your confusion.

---

First let us define what exactly a remote repository is. In the world of git a remote repository is nothing else but a repository you have registered in your local repository via the git remote command.
This repository doesn't even need to have common history with your local repository, it doesn't need to be bare, it doesn't need to exist on a server - it could even be in the same folder on your local machine - it just needs to be registered via git remote in your local repository to be considered a remote repository.

Fairly general, isn't it?

When working in a team a common workflow in git would be to define a central repository which all developers register as remotes. When cloning a repository (git clone) this repository will have the cloned repository registered as a remote repository.

Each developer can now work locally and push their changes to this central repository; the other developers can fetch this changes from there.

But it doesn't need to be this way.

Git is a distributed version control system, this means that every clone of a repository is a complete backup and can function as a remote repository (to use the git term).

What does that mean for us? It means that the workflow of a central repository only is a common agreement in the team to consider this one repository as the true one.

---

Now let's back to your confusion:

As long as you are, for example, following the workflow of a central repository no push will change your local clone of the repository (means git status will never "change on it's own").

If I understood your comments correctly, User B cloned User A's repository. What have we learned about cloning a repository? The repository of User A is now considered a remote repository in User B's clone.

This means that each push User B does will push his changes into User A's repository - by default git won't allow pushes into non-bare repositories but it's possible. Such a push could effectivly change the output of git status even though User A hasn't made any changes but User B has with his push.