summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <junkio@cox.net>2005-07-22 19:13:07 -0700
committerLibravatar Linus Torvalds <torvalds@g5.osdl.org>2005-07-22 20:34:17 -0700
commita692b9656a7975b933fde40cdd6319f9ca898a29 (patch)
tree315760a2f96b0e044e6dfe0efbd1d24791e638f9 /Documentation
parent[PATCH] git-clone-script: store where we cloned from in .git/branches/origin (diff)
downloadtgif-a692b9656a7975b933fde40cdd6319f9ca898a29.tar.xz
[PATCH] tutorial: mention "git clone" records .git/branches/origin
Update the recommended workflow for individual developers. While they are tracking the origin, refs/heads/origin is updated by "git fetch", so there is no need to manually copy FETCH_HEAD to refs/heads/ anywhere. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/tutorial.txt40
1 files changed, 18 insertions, 22 deletions
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 925ef2c401..4a29607915 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -1042,7 +1042,8 @@ A recommended work cycle for a "subsystem maintainer" that works
on that project and has own "public repository" goes like this:
(1) Prepare your work repository, by "git clone" the public
- repository of the "project lead".
+ repository of the "project lead". The URL used for the
+ initial cloning is stored in .git/branches/origin.
(2) Prepare a public repository accessible to others.
@@ -1051,7 +1052,7 @@ on that project and has own "public repository" goes like this:
currently not automated.
(4) Push into the public repository from your primary
- repository. Run "git repack" (and possibly "git
+ repository. Run "git repack", and possibly "git
prune-packed" if the transport used for pulling from your
repository supports packed repositories.
@@ -1076,30 +1077,25 @@ A recommended work cycle for an "individual developer" who does
not have a "public" repository is somewhat different. It goes
like this:
- (1) Prepare your work repositories, by "git clone" the public
- repository of the "project lead" (or "subsystem
- maintainer", if you work on a subsystem).
-
- (2) Copy .git/refs/master to .git/refs/upstream.
-
- (3) Do your work there. Make commits.
+ (1) Prepare your work repository, by "git clone" the public
+ repository of the "project lead" (or a "subsystem
+ maintainer", if you work on a subsystem). The URL used for
+ the initial cloning is stored in .git/branches/origin.
- (4) Run "git fetch" from the public repository of your upstream
- every once in a while. This does only the first half of
- "git pull" but does not merge. The head of the public
- repository is stored in .git/FETCH_HEAD. Copy it in
- .git/refs/heads/upstream.
+ (2) Do your work there. Make commits.
- (5) Use "git cherry" to see which ones of your patches were
- accepted, and/or use "git rebase" to port your unmerged
- changes forward to the updated upstream.
+ (3) Run "git fetch origin" from the public repository of your
+ upstream every once in a while. This does only the first
+ half of "git pull" but does not merge. The head of the
+ public repository is stored in .git/refs/heads/origin.
- (6) Use "git format-patch upstream" to prepare patches for
- e-mail submission to your upstream and send it out.
- Go back to step (3) and continue.
+ (4) Use "git cherry origin" to see which ones of your patches
+ were accepted, and/or use "git rebase origin" to port your
+ unmerged changes forward to the updated upstream.
-[Side Note: I think Cogito calls this upstream "origin".
- Somebody care to confirm or deny? ]
+ (5) Use "git format-patch origin" to prepare patches for e-mail
+ submission to your upstream and send it out. Go back to
+ step (2) and continue.
[ to be continued.. cvsimports ]