Re: Possible to make a totally empty repository for remote access?

From: Wincent Colaiuta <win@wincent.com>
Date: Jul 14, 2007, 02:19 UTC
Message-ID: <95A1FBFA-DCB7-4767-B857-89660822C6E6@wincent.com>
In-Reply-To: <7vtzs8lzgk.fsf@assigned-by-dhcp.cox.net>

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

> 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.

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