What's the most straightforward way to clone an empty, *bare* git repository?

Question

I've just finished cruising the Google search results that contain all the email rants about how stupid it is that git can't clone an empty repository. Some kind soul even submitted a patch. Until git is upgraded, what is the simplest, most straightforward method to clone an empty, bare git repository?

The ideal solution will support the -o option to give the remote repo a name other than origin, and it will be implementable as a simple shell script, e.g., git-clone-empty-repo.

(Why I want to do this: I've set up a bare, empty git repo on our NetApp filer where it will be backed up, but I want to work with a clone on my local hard drive and push and pull back and forth. Other people I work with will be doing the same. I create new git repos a lot and my inability to clone an empty repo makes me crazy.)

---

EDIT: VonC's thread suggests that

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

is equivalent to cloning the remote repo when the repo is empty. This is not quite what I want because I always use the -o option with git clone; I name the remote repo according to what machine it is on or some other memorable criterion. (I have too many repos to keep them straight if they're all called origin.)

---

EDIT: The following answer will be marked accepted :-)

To clone an empty, bare repo at path,

1. Keep at ~/git/onefile a non-bare git repo containing one innocuous file such as .gitignore. (Alternatively, create such a repo dynamically.)
2. (cd ~/git/onefile; git push path master)
3. git clone -o name path

In other words, don't attempt to clone the empty repo, but rather after creating it, push to it a simple repo containing one innocuous file. Then it is no longer empty and can be cloned.

If someone does not beat me to it, I will post a shell script.

Answer 1

May be just have a git repo with the minimum number of file in it:

one: .gitignore with obvious ignore patterns in it.

And then clone that "almost empty" repository.
Note that such an "almost empty" repository ("almost" because it still has a minimal working directory alongside the .git directory) can then by 'git clone --bare' (as illustrated here), making it a true bare repo (but not an "empty" one).
This is that bare repo you can then:

• clone everywhere you want.
• or (more importantly) push to (since it is a bare repo)

---

You have in this thread a good summary of the "other way around" (which I keep here for reference).

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

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.

To which Junio C Hamano responded:

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.