Possible to make a totally empty repository for remote access?

For a new project (no code yet) I wanted to make an empty, bare repository (no working copy) on a remote public server as a starting point, clone it locally, and gradually create content locally and push it out to the remote, public server.

But so far I've been unable to do so in a straightfoward fashion...

mkdir test.git cd test.git git --bare init touch git-daemon-export-ok

If I try to clone such an empty repository I get:

fatal: no matching remote head

And GIT_DIR/HEAD points to refs/heads/master, which doesn't exist yet.

Same if I go for a non-bare, but still empty repository:

mkdir test cd test git init touch .git/git-daemon-export-ok

Only after adding actual content can I clone without getting the "no matching remote head" error:

echo "foo" > bar git add bar git commit -m "foobar"

Then cloning works.

I understand that Git is a *content* manager and a totally empty repository has no content, and therefore no tree object which the HEAD can point to. But the trouble with adding content the way I describe above, is that my public repository is no longer bare; it now has a working copy, which I didn't really want.

What's the way around this? Do I start with a non-bare repository, add any old bogus content, and then convert it to bare and blow away the working copy?

mkdir test cd test git init touch .git/git-daemon-export-ok touch .gitignore git add .gitignore git commit -m "Initial empty repository containing only an empty .gitignore file" git config core.bare true mv .git ../test.git cd .. rm -r test

Is there a better way? Am I missing something obvious?

Cheers, Wincent

Wincent Colaiuta <win@wincent.com> writes:

You prepared an empty bare repository for publishing, and that is very good.

The next step is that you prepare your contents elsewhere. That would be your private working place, i.e. the place you would normally work in). You push from your private working place into that publishing repository. Your working place is where the very initial commit should come from, since you are the one who is starting the project.

Note that the private working place does not have to be a clone of the empty one. That actually is backwards. Your work started from your private working place to the publishing one.

You could even clone your private repository to publishing one to make it clear who is the master and who is the copy if you wanted to, but because you already have the bare repository for publishing, just pushing into it is all that is needed.

El 14/7/2007, a las 0:18, Junio C Hamano escribió:

Thanks very much for the clarification, Junio. I didn't realize I could push like that (thought it had to be from a clone); that's very flexible indeed.

For the benefit of others who might stumble across this question in the archives, the basic pattern is:

# create the bare, empty public repository on the remote server: mkdir test.git cd test.git git --bare init touch git-daemon-export-ok

# locally, create some initial content mkdir test cd test git init vi foobar # etc git add . git commit -s git tag -s v0.0.1

# push initial contents git push git.server.example.com:/pub/git/test.git master

This assumes that you have git-daemon set up to provide public read- only access, and appropriate SSH accounts and configuration for those who need write access, but that's all fairly well documented elsewhere (ie in the git-daemon man page, and in abundant information on the web about setting up SSH access with public-key auth).

To make such pushes easier in the future you can create a local shortcut file, .git/remotes/shortcut (or similar), with contents like:

URL: git.server.example.com:/pub/git/test.git
Push: master

If other developers will have write access to the remote repo then you can add "Pull:" statements as well so as to keep up to date (as detailed in the git-push man page, and in the "Everyday GIT With 20 Commands Or So" document: <http://www.kernel.org/pub/software/scm/git/ docs/everyday.html>), and you can synchronize multiple branches in both directions by adding additional "Push:" and "Pull:" declarations. With the shortcut file in place you could have written the above push as:

git push shortcut

To push your initial tag you would do:

git push shortcut v.0.0.1

(Or you could have included the tag in the original push by passing the --tags switch.)

One thing to note: the ".git/remotes/shortcut" file should not be confused with the directories under ".git/refs/remotes".

Finally, now that the remote repository actually has some content in it you also have the option of just creating a fresh local clone of it, and thus benefitting from the automatic set-up that "git clone" does for you:

git clone git://git.server.example.com/test

The Git documentation is shockingly good; almost too good: there is so much of it that sometimes it can be hard to find exactly what you're looking for. For reference, the "Git core tutorial for developers" was the one place which I could find which explicitly talked about the missing piece of the puzzle: pushing from a private repo (not a clone) to an empty public one:

<http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html>

Cheers, Wincent

On Sat, Jul 14, 2007 at 04:19:41AM +0200, Wincent Colaiuta wrote:

The "new" way (by "new" I mean available for over a year, since v1.4.1) is to put such configuration into your .git/config file:

[remote "shortcut"]
  url = git.server.example.com:/pub/git/test.git

Though if this is going to be the upstream from which you will be pushing and pulling, you may want to call it "origin" (which will make it the default for pushing and pulling).

Even more simply, you can get the same remote config that git-clone would have set up by using the git-remote command:

  $ git-init
  $ git-remote origin server:/pub/git/test.git

-Peff

On Fri, Jul 13, 2007 at 10:58:19PM -0400, Jeff King wrote:

Sorry, this should be:

  git-remote add origin server:/pub/git/test.git

-Peff

also sprach Jeff King <peff@peff.net> [2007.07.14.0458 +0200]:

Have a look also at

  http://blog.madduck.net/vcs/2007.07.11_publishing-git-repositories