0

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

WITL
  • 107
  • 1
  • 9
  • They are talking about user b pushing directly to user A's repo, and pushing to the currently checked out branch. – Andrew C Jan 06 '15 at 06:14
  • '@Andrew, excuse me but your answer seems to elude me. can you explain pls ? how can USER B push directly into user A's repo? I assume user b clones user A's repository, and then he adds a file and commits it. Under this scenario these user B's actions are done his local machine-- how can he push it directly to user A who works on his local directory on another machine such that user A's git status command will display different results than what he had previously had produced with same command while not having performed any change on his machine? – WITL Jan 06 '15 at 06:29
  • in that case, user B pushes his commits; user A must fetch or lone the new updated repository -- that is in negation what gitguys link stated above - -that all that user A did is run git status at one point in time nd the he ran it again only to find changes that he did not commit . please advise – WITL Jan 06 '15 at 07:10
  • User A don't need to fetch if B pushes his changes into A's repository. He just needs to fetch if both push to and fetch from a common remote repository. – Sascha Wolf Jan 06 '15 at 07:12
  • @Zeeker can you pls explain (as I am still learning) how user A can create that repository which, as you said, is not a common repository; as well can you explain how he can create "common repository". what i am trying to get it by these means (of knowing the difference between these 2 types of repositories) is how user b's "git push" leads to his changes end up in the directory of user A . From my poor understanding, user's B "git push" command should upload the commits to a repository which user A will need to fetch from in order to observe the changes with git status. – WITL Jan 06 '15 at 07:29

1 Answers1

0

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.

Sascha Wolf
  • 18,810
  • 4
  • 51
  • 73
  • Zeeker hi. Much appreciation for caring about those who read your answer (which is an exceptional merit in this website); and I am sorry for my delayed response. I can now see what I wanted to believe in and I could not. That is, before I decided to post the question in this website, at some point it crossed my mind that the only incident where one user working locally might affect the work of another user working locally is that they physically share the same folder, but I dismissed that possibility because – WITL Jan 07 '15 at 20:30
  • I was convinced that remote repositories are such repositories which cannot be local. Your answer clarified that by shedding light on where remote repository could be in relation to a user. At any are, I wanted to hone my understanding in terms of a scenario, if I may. Specifically– and please correct me if I am wrong – there exist a scenario where user A might create a local empty, non-bare repository (with git init command WITHOUT bare option) which user B would clone thereafter (with git clone). – WITL Jan 07 '15 at 20:31
  • I was convinced that remote repositories are such repositories which cannot be local. Your answer clarified that by shedding light on where remote repository could be in relation to a user. At any are, I wanted to hone my understanding in terms of a scenario, if I may. Specifically– and please correct me if I am wrong – there exist a scenario where user A might create a local empty, non-bare repository (with git init command WITHOUT bare option) which user B would clone thereafter (with git clone). It might be a redundant question but I just wanted to know whether I got it right. – WITL Jan 07 '15 at 20:31
  • Thanks! one thing with respect to the aforementioned scenario in these comments which i might need to pose an additionla question -- depending on what really happens. Could you tell me what user A will see in git status assuming that user B pushed a file by the name UserBaddedfile.txt ? Might seem a trivial question, but this question comes to clarify what exactly is pushed to the working directory of user A. If user A has exactly the same files of user B (after the push0, including the history of changes, then shouldn't user A see a message saying "nothing to commit", similar to user B's ? – WITL Jan 07 '15 at 20:57