path: root/Documentation
diff options
authorJunio C Hamano <>2005-08-24 23:46:11 (GMT)
committerJunio C Hamano <>2005-08-24 23:50:55 (GMT)
commitc95173410d6f290e65c15232e56f4963f8279ef1 (patch)
tree4ebc6433d7f2a498d22a44f984f9a315d0b483cc /Documentation
parentab9b31386b494b6c16d651d1560f3ba11c3a1964 (diff)
Update tutorial to describe shared repository style a bit more.
Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'Documentation')
1 files changed, 53 insertions, 20 deletions
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 876a4af..997e958 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -892,18 +892,26 @@ pull from:
It is likely that you will be pulling from the same remote
repository from time to time. As a short hand, you can store
-the remote repository URL in a file under .git/branches/
+the remote repository URL in a file under .git/remotes/
directory, like this:
- mkdir -p .git/branches
- echo rsync:// \
- >.git/branches/linus
+mkdir -p .git/remotes/
+cat >.git/remotes/linus <<\EOF
and use the filename to "git pull" instead of the full URL.
-The contents of a file under .git/branches can even be a prefix
+The URL specified in such file can even be a prefix
of a full URL, like this:
- echo rsync:// >.git/branches/jgarzik
+cat >.git/remotes/jgarzik <<\EOF
@@ -913,9 +921,9 @@ Examples.
the above are equivalent to:
- (1) git pull rsync:// HEAD
- (2) git pull rsync:// tag v0.99.1
- (3) git pull rsync:// e100
+ (1) git pull HEAD
+ (2) git pull tag v0.99.1
+ (3) git pull e100
Publishing your work
@@ -1169,18 +1177,43 @@ Working with Others, Shared Repository Style
If you are coming from CVS background, the style of cooperation
suggested in the previous section may be new to you. You do not
have to worry. git supports "shared public repository" style of
-cooperation you are more familiar with as well.
-For this, you should set up a public repository on a machine
-that are reachable via SSH by people with "commit privileges".
-Put them in the same user group and make the repository writable
-by that group. Then, each committer would first merge with the
-head of the branch of choice, and run "git push" to update the
-branch at the public repository. "git push" refuses to update
-if the reference on the remote side is not an ancestor of the
-commit you are pushing, to prevent you from overwriting changes
-made by somebody else.
+cooperation you are probably more familiar with as well.
+For this, set up a public repository on a machine that is
+reachable via SSH by people with "commit privileges". Put the
+committers in the same user group and make the repository
+writable by that group.
+Each committer would then:
+ - clone the shared repository to a local repository,
+$ git clone repo.shared.xz:/pub/scm/project.git/ my-project
+$ cd my-project
+$ hack away
+ - merge the work others might have done while you were
+ hacking away.
+$ git pull origin
+$ test the merge result
+ - push your work as the new head of the shared
+ repository.
+$ git push origin master
+If somebody else pushed into the same shared repository while
+you were working locally, the last step "git push" would
+complain, telling you that the remote "master" head does not
+fast forward. You need to pull and merge those other changes
+back before you push your work when it happens.
[ to be continued.. cvsimports ]