GIT: How to see pulled/pushed changes in origin

Question

I've just started using Git (previously Subversion). I'm having real problems getting my head round being unable to see pushed or pulled changes in the original repository. My 'architecture' is this:

MAIN CODEBASE

  -->Development repository 1
  -->Development repository 2

When I push changes from one of the dev repos back up to the MAIN CODEBASE, I can't see the changes there.

When I subsequently pull from the MAIN CODEBASE, all the previous changes in that dev repo are overwritten.

I'm clearly missing one or more points here, and I'm getting very confused by documentation that seems to assume I know the 'obvious'. As it stands, Git seems useless to me and I'm wondering whether to go back to Subversion - it was certainly easier to learn and understand.

Deltadeltaic

Just added the publication architecture to my answer. – Markova

Answer 1

It looks like the question Why won't I see changes in the remote repo after "git push"?

The push operation is always about propagating the repository history and updating the refs, and never touches the working tree files.
In particular, if you push to update the branch that is checked out in a remote repository the files in the work tree will not be updated.

This is a precautionary design decision.
The remote repository's work tree may have local changes, and there is no way for you, who are pushing into the remote repository, to resolve conflicts between the changes you are pushing and the ones in the work tree

As said, a bare remote repo is better here.
You can setup a non-bare repo in the same place than MAIN CODEBASE, in order to see the changes in that "non-bare main codebase repo".

Note: with the upcoming Git 1.7, git push into a branch that is currently checked out (i.e. pointed by HEAD in a repository that is not bare) will be refused by default.

git pull should not overwrite anything, at least not without big warnings. Do you see any of those warning messages?

---

As kibitzer aptly describes in the comment:

bare means a repository which does not contain the actual files, just the metadata (commits). Pushes to such repository are safe because no discrepancy is generated between the state of files on disk and commits in .git

The fact that this remote repo is "empty" (it only has the .git folder, but no file checked-out) does not mean a git clone will result in an empty local repo.
It will create and check-out an initial branch that is forked from the cloned repository's currently active branch.

---

So, the "publication architecture" would be:

/---
| MAIN SERVER   :   [     BARE-MAIN-REPO    ] == (pull only) ==> [ MAIN-REPO ]
\---                    ^^    ||   ^^   ||
                        ||    ||   ||   ||
                       push  pull push pull
                        ||    ||   ||   ||
/---                    ||    vv   ||   ||
|DEV1 PC        :    [ DEV1 REPO ] ||   ||
\---                               ||   ||
                                   ||   ||
/---                               ||   vv
|DEV2 PC        :               [ DEV2 REPO ]
\---

Note: if you refer to the Git Glossary, what "origin" means is the default upstream repository.
Bare-main-Repo is the "origin", i.e. the default upstream repo for dev1 and dev2, meaning both those repos wll have been created by cloning Bare-main-Repo.
(Nothing prevents you to add other upstream repos: dev1 could add dev2 as another upstream repo, allowing to pull directly from dev2 for instance)

Markova

Of course I'm aware of your reference to the FAQ, but I'm failing to see the point of being unable to return a modified clone to a central point. How do I get to a situation where I for example, can make changes to PHP and my designer can make changes to templates and we can merge our changes so that a third person can checkout the latest version? – Deltadeltaic

I have not yet found an understandable explanation of what a bare repo is, nor how to merge it back into the non-bare. One point of confusion is the reference to working copies and remote repos - what is the original called and what is my local copy called? If the original is untouchable why does it exist? Git pull overwrote quietly. – Deltadeltaic

See also stackoverflow.com/questions/738154/… – Markova

bare means a repository which does not contain the actual files, just the metadata (commits). Pushes to such repository are safe because no discrepancy is generated between the state of files on disk and commits in .git – Wincer

Okay, I understand that, but if the main codebase is a bare repository containing no more than a .git folder, what is it a repository of? I can't clone anything from it because there won't be anything there. – Deltadeltaic

You can clone from a bare repository-clone does not read the working directory anyway. – Borowski

Right. So what is the architecture here? Is it ORIGIN->BARE_CLONE->||->REMOTE_COPY or ORIGIN->||->REMOTE_BARE_CLONE->REMOTE_COPY or BARE_ORIGIN->||->REMOTE_COPY or ORIGIN->||->BARE_REMOTE_COPY ? – Deltadeltaic

Thanks, VonC, it's becoming a little clearer now. I'll have to do some experimentation before my confidence is restored, though. I'm still a little unsure what will happen to the main codebase - will it ever be updated? Looks to me like this just moves the problem upstream. – Deltadeltaic

@Leo: upstream (here "bare-main-repo") will be updated, but will stay empty (as all bare repos do). A pull from "main-repo" will reflect the changes updated in bare-main-repo, because main-repo is checked out. – Markova

Answer 2

When you push changes to the main codebase, the git archive is update, but the checked-out working directory of the main codebase is not.

I strongly suggest you make the main codebase a --bare repository, which will prevent this confusion.

I don't know what the problem is the overwriting previous changes, that doesn't seem right to me - can you give an example?

The manpages are not there for beginners, as a tutorial, but to remind someone who already understands git how to use some feature that they are hazy about. There's plenty of documentation and howtos on the web, including the user manual.

Borowski

Please can you explain, or point me to an intelligible explanation of, bare repositories. I'm having real problems with the manpages style of documentation that abounds (where each page assumes you already understand all of the others - catch 22). – Deltadeltaic

Overwriting: can't really supply any output as there wasn't any, bu the process went like this: 1->edit code; 2->commit code [repo okay]; 3->push (or pull) [repo okay]; 4->commit origin [origin doesn't show changes]; 5->pull (or push) [repo overwritten] – Deltadeltaic

don't commit the origin - this is most likely your problem. You can run git reset --hard HEAD on the origin, if you like. – Borowski

You need to read the documentation for git - the man pages are just reminders for someone who already knows how to use git, not a tutorial. – Borowski

You misunderstand me. I was saying that the documentation is in the style of manpages and as such is not very user friendly. By editing your original answer in this respect you have made this sub thread confusing. – Deltadeltaic

I'm sorry for adding confusion to this thread, but on stackoverflow it's common to update answers in this way, and I checked that the enhanced answer made sense with respect to your original question. Hit is confusing for beginners, but there is plenty of introductory documentation that isn't in the form of manpages. – Borowski

Answer 3

I think the other answers are using a lot of technobabble to try to answer a very simple misunderstanding about the way repositories work, so I will try to answer more simply:

A repository is a controlled version of a directory, where each file that anyone adds or modifies is tracked. This may not look anything like a directory that you are used to. For example, you can't open it in Windows Explorer or type 'ls' on UNIX to see its contents.

A git repository sits within a '.git' directory within your normal filesystem. If you open it up, it looks somewhat unrecognizable. In your case there is one of these repositories on each development machine and on the MAIN CODEBASE machine (this is why git is called a distributed version control system). Remember, this repository is different from the actual files, which usually appear in the same directory as the .git directory. Therefore if you push to your main repository, the actual files sitting next to the repository don't get changed at all - only the repository does. If those files don't exist at all, you have a bare repository like others have mentioned.

For purposes of comparison, a svn repository sits only in one place, usually on a server in a totally separate location from the actual files themselves. Like in a git repository, opening up this directory shows some unrecognizable files. Most people never even care about this, since when they check out files, they get all the contents onto their local machine.

To make a long story short, if you want to have a main codebase machine, it doesn't need the files at all, just the repository. This is true for both SVN and git.

Marbut

Okay, but if I feed back my changes to a bare repo on the 'main codebase' machine, where do the actual files go? – Deltadeltaic

In git, the 'actual files' in a repository on a server are called "blobs" and sit in the .git directory. You can read more about this here: book.git-scm.com/1_the_git_object_model.html – Marbut

Answer 4

I think we need more information, perhaps post some git status output and so on?

From what you've got here I'd say your remote (origin) repositories aren't 'bare'. All 'central'-like repositories should be bare. Just because you push to a repository doesn't mean it should update it's working copy (what if it has changes!?).

In other questions you are asking what a bare repository is.

A bare repository is, quite simply, a repository without a working copy.

Laughlin

No, they aren't bare. I followed this tutorial: kernel.org/pub/software/scm/git/docs/gittutorial.html It doesn't mention bare. – Deltadeltaic

Then that is your problem, remote repos meant for organizing teams and the like should be bare. If you want to then 'deploy' from this repo you simple clone it into another location and update it manually (or with some kind of script/automation). – Laughlin