diff options
author | Junio C Hamano <junkio@cox.net> | 2005-07-22 19:13:07 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2005-07-22 20:34:17 -0700 |
commit | a692b9656a7975b933fde40cdd6319f9ca898a29 (patch) | |
tree | 315760a2f96b0e044e6dfe0efbd1d24791e638f9 | |
parent | [PATCH] git-clone-script: store where we cloned from in .git/branches/origin (diff) | |
download | tgif-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>
-rw-r--r-- | Documentation/tutorial.txt | 40 |
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 ] |