On Sat, Sep 20, 2014 at 4:02 AM, Tom Hopcraft <sub...@admiretheweb.com> wrote:
> Hi,
> I have just moved host and my old git setup was to have a working repo on
> the server and then clone that working repo locally. I also run Wordpress
> and when I upload files through Wordpress this would add files to the live
> hosting that I would not have locally. To get this locally I would have to
> SSH into the server and git add -A and commit them, I would then fetch them
> locally.
> --
> I have done some reading up about the best way to migrate git repo's to new
> servers as I'd like to keep my history, naturally.
> I have read that the live server shouldn't have a working repo but a bare
> repo. That is fine by me, but then how do I SSH in and find the files ?

You don't. All the files in a bare repository are in git's internal
"compressed" format. It is not intended that anyone SSH into the
server and access the bare repository as if it were a normal, working,

> The
> root on the server now contains foo.git and no files where as a working repo
> would contain a hidden .git and then foo.html, bar.html.

Very true. This is how git is designed.

> I'm confused as to why you shouldn't use a working repo on the server and if
> you are to use a bare repo, how does example.com/foo.html get found ?

A bare repository is not a working directory. It is meant to be a
source/sink for git clone or fetch and git push. Just like an
Subversion server is not to be used as a place to modify the files
managed by the Subversion system.

> Thanks

Basically, the way that I think of it, is that the bare repository is
the "off site" storage location where the "master copy" is kept. When
you want to do work on a project, you first do a "git clone" to create
a working directory on your work PC (which might or might not be the
same physical system). This creates a new directory on your machine.
This directory contains a .git subdirectory which contains all of the
git repository information (all versions of all files) and also
contains a current working copy of the files themselves. You modify
these files. Periodically, as you think necessary or according to some
standard, you do a "git add" of the files you have changed and
sometime (perhaps immediately) afterwords do a "git commit" to put the
modified files and a comment into _your local_ version of the project.
Again, at some point in time, you do a "git push". This contacts the
PC which contains the bare repository (aka the "git server") and tries
(explain in a bit) to update it with your changes. This may or may not
succeed. It will fail if someone else has updated the bare repository
after your last "git fetch" of it. You must then "git fetch" and do a
"git merge" to merge the bare repositories view of the project with
your local view. If this succeeds, then do a "git push" again and you
are finished. Otherwise, you will be told by "git merge" that there is
a conflict that you must resolve. Once you do that, you can do a the
"git add", "git commit", and "git push" sequence again to update the
bare repository.

I hope that I made some sense to you. I often don't. <sigh/>

BTW - I don't know anything about WordPress, so I can't make any
comment about that. But perhaps these will help:

There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to