From e7c1ca4273e3306760f220ea1e6c4685aa7a8b92 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 15 Jul 2005 00:59:34 -0700 Subject: [PATCH] [PATCH] Documentation: update tutorial to talk about push. Talk about publishing to a public repository. Also fixes a couple of typos. Signed-off-by: Junio C Hamano Signed-off-by: Linus Torvalds --- Documentation/tutorial.txt | 87 +++++++++++++++++++++++++++++++++++--- 1 file changed, 80 insertions(+), 7 deletions(-) diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index 87feac77e..50ac92718 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -480,9 +480,10 @@ This has two implications: history outside of the project you created. - if you want to move or duplicate a git archive, you can do so. There - is no "git clone" command: if you want to create a copy of your - archive (with all the full history that went along with it), you can - do so with a regular "cp -a git-tutorial new-git-tutorial". + is "git clone" command, but if all you want to do is just to + create a copy of your archive (with all the full history that + went along with it), you can do so with a regular + "cp -a git-tutorial new-git-tutorial". Note that when you've moved or copied a git archive, your git index file (which caches various information, notably some of the "stat" @@ -534,7 +535,7 @@ create your own copy of the git repository, you'd do the following mkdir my-git cd my-git - rsync -rL rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/ .git + rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git .git followed by @@ -549,14 +550,14 @@ those, you'd check them out with where the "-u" flag means that you want the checkout to keep the index up-to-date (so that you don't have to refresh it afterward), and the -"-a" file means "check out all files" (if you have a stale copy or an +"-a" flag means "check out all files" (if you have a stale copy or an older version of a checked out tree you may also need to add the "-f" -file first, to tell git-checkout-cache to _force_ overwriting of any old +flag first, to tell git-checkout-cache to _force_ overwriting of any old files). Again, this can all be simplified with - git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/ my-git + git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git cd my-git git checkout @@ -769,4 +770,76 @@ want to do - any time you decide that you want to remember a certain point, just create a private tag for it, and you have a nice symbolic name for the state at that point. + + Publishing your work + -------------------- + +We already talked about using somebody else's work from a remote +repository, in the "merging external work" section. It involved +fetching the work from a remote repository; but how would _you_ +prepare a repository so that other people can fetch from it? + +Your real work happens in your working directory with your +primary repository hanging under it as its ".git" subdirectory. +You _could_ make it accessible remotely and ask people to pull +from it, but in practice that is not the way things are usually +done. A recommended way is to have a public repository, make it +reachable by other people, and when the changes you made in your +primary working directory are in good shape, update the public +repository with it. + +[ Side note: this public repository could further be mirrored, + and that is how kernel.org git repositories are done. ] + +Publishing the changes from your private repository to your +public repository requires you to have write privilege on the +machine that hosts your public repository, and it is internally +done via an SSH connection. + +First, you need to create an empty repository to push to on the +machine that houses your public repository. This needs to be +done only once. + +Your private repository's GIT directory is usually .git, but +often your public repository is named ".git". +Let's create such a public repository for project "my-git". +After logging into the remote machine, create an empty +directory: + + mkdir my-git.git + +Then, initialize that directory with git-init-db, but this time, +since it's name is not usual ".git", we do things a bit +differently: + + GIT_DIR=my-git.git git-init-db + +Make sure this directory is available for others you want your +changes to be pulled by. Also make sure that you have the +'git-receive-pack' program on the $PATH. + +[ Side note: many installations of sshd does not invoke your + shell as the login shell when you directly run programs; what + this means is that if your login shell is bash, only .bashrc + is read bypassing .bash_profile. As a workaround, make sure + .bashrc sets up $PATH so that 'git-receive-pack' program can + be run. ] + +Your 'public repository' is ready to accept your changes. Now, +come back to the machine you have your private repository. From +there, run this command: + + git push :/path/to/my-git.git master + +This synchronizes your public repository to match the named +branch head (i.e. refs/heads/master in this case) and objects +reachable from them in your current repository. + +As a real example, this is how I update my public git +repository. Kernel.org mirror network takes care of the +propagation to other publically visible machines: + + git push master.kernel.org:/pub/scm/git/git.git/ + + [ to be continued.. cvsimports, pushing and pulling ] -- 2.26.2