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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
