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 <[EMAIL PROTECTED]>
---
Documentation/tutorial.txt | 48 ++++++++++++++++++++------------------------
1 files changed, 22 insertions(+), 26 deletions(-)
6af33a52163dd15beaaf610f6b7506b900189770
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -1042,7 +1042,8 @@ A recommended work cycle for a "subsyste
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 repo
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 "individ
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.
-
- (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.
-
- (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.
-
- (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.
-
-[Side Note: I think Cogito calls this upstream "origin".
- Somebody care to confirm or deny? ]
+ (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.
+
+ (2) Do your work there. Make commits.
+
+ (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.
+
+ (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.
+
+ (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 ]
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
