1

I am following the examples here http://wiki.dreamhost.com/Git

Basically I want to create a git repo i can push to on a server from my desktop... On host:

[host ~]$ mkdir project.git
[host ~]$ cd project.git
[host project.git]$ git init --bare
[host project.git]$ exit

Then locally:

[local ~]$ cd project
[local project]$ git init
[local project]$ touch .gitignore
[local project]$ git add .
[local project]$ git commit

On host if i CD into the directory.. I am shown the following files (which usually sit in the .git dir)

HEAD  branches  config  description  hooks  info  objects  refs

On local I then create a remote push: git remote add origin ssh://XXX@XXX/home/XXX/XXX/ It pushes says it has worked...

Counting objects: 3, done.
Writing objects: 100% (3/3), 210 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)

However when I go back to the working folder on the server, there is nothing there.. it is just the .git files listed above.

I have done this before and it worked this way... just this time I must be doing something wrong.

UPDATE

If I try to create the repo on the server without --bare ... then I get this error on push

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

UPDATE AND RESOLUTION....

I found this which works really well http://toroid.org/ams/git-website-howto

Essentially use a --bare then have hook which copies your latest commit to a working directory!

Charlie Davies
  • 1,814
  • 4
  • 29
  • 50

2 Answers2

3

What you see seems correct. The .git files you see in that folder (and a lot of it in the objects directory) contains all your git repository.

When you make a "bare" repository, this prevents anybody else to edit the files directly there (on your host machine), not having the project checked out with all your source file is one of the thing that would prevent such editing.

Matthieu
  • 16,103
  • 10
  • 59
  • 86
  • thanks, so am I doing this the wrong way? Essentially I just want to make a remote folder pushable to i can push from command on local – Charlie Davies Jul 17 '12 at 14:49
  • 1
    you allready have achieved that. Its just that a bare repository does handle its content differently then a local working rep. Therefore you don´t see the files which you expect to be there. Nothing wrong with that. – Th 00 mÄ s Jul 17 '12 at 14:57
  • @ThomAS thanks, so how do I "see" those files? What is the path? – Charlie Davies Jul 17 '12 at 15:12
  • 1
    You don´t see them. Its not the purpose a bare rep. If you want to see the files you can A) check out a seperate working dir B) Don´t use a bare rep in the first place. – Th 00 mÄ s Jul 17 '12 at 15:15
  • Like ThomAS said... to "see" the files, you'd have to clone the repository in another location. There might be other ways but that would be the easiest by far. – Matthieu Jul 17 '12 at 15:52
2

git init --bare creates a "bare" repository - one that does not have a working directory associated with it. What you are seeing is what is expected. If you want a separate repository that has a checked out working directory associated with it, don't use the --bare option, but note that doing so has additional implications, because git push acts differently when the remote is not a bare repository, in order to protect you from losing any unstaged/uncommitted changes you may have in the remote.

twalberg
  • 59,951
  • 11
  • 89
  • 84
  • Depends on the use case - many of my projects have one normal repository and one bare one that I push to as a backup. A few have multiple normal repositories with working directories so I can work in either place, but I usually don't push from those - instead, I fetch/merge to get the updates. Usually in these cases I'll also have a bare repository to push to for backup purposes as well. – twalberg Jul 17 '12 at 15:16
  • okay, all I really want is one remote repo, one local. So I can git push remote master to move code from local to server – Charlie Davies Jul 17 '12 at 15:18
  • 1
    In that case, your original setup (bare remote repo) is probably the best, but you won't be able to browse the code in the remote - you can still do `git log` and other stuff to browse the revision history, though. If you need to look at the code on the remote for some reason, you can always create a throw-away non-bare clone that has a working directory. – twalberg Jul 17 '12 at 15:32
  • Usually bare repos are used to exchange code or to be a "blessed repository" For example you can have several developers working on the same project and same repo, but they all push to one "central" bare repo. It is not recommended to push to NON-bare repo There are tools that are allowing you to browse code on bare repos like CGIT, gitweb etc. Every time you need to get the code out from this bare repo for deployment you just clone/pull from it. It is not recommended to push to NON-bare repo. – Eugene Sajine Jul 17 '12 at 19:51