undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[PATCH] Documentation: update recommended workflow when working with others.

Browse Source 
Clarify that the hierarchy implied by the recommended workflow
is only informal.

Refer readers to nice illustration by Randy Dunlap.

Separate out the step to "push" to own public repository in the
workflow.

Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This commit is contained in:
Junio C Hamano 2005-07-15 20:56:12 -07:00 committed by Linus Torvalds
parent 2c38fe4c57
commit a232a132ea
1 changed files with 42 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
Documentation/tutorial.txt
View File

@ -967,7 +967,19 @@ unpacked in the destination, unless rsync transport is used.
Working with Others Working with Others
------------------- -------------------
A recommended work cycle for a "project lead" is like this: Although git is a truly distributed system, it is often
convenient to organize your project with an informal hierarchy
of developers. Linux kernel development is run this way. There
is a nice illustration (page 17, "Merges to Mainline") in Randy
Dunlap's presentation (http://tinyurl.com/a2jdg).
It should be stressed that this hierarchy is purely "informal".
There is nothing fundamental in git that enforces the "chain of
patch flow" this hierarchy implies. You do not have to pull
from only one remote repository.
A recommended workflow for a "project lead" goes like this:
(1) Prepare your primary repository on your local machine. Your (1) Prepare your primary repository on your local machine. Your
work is done there. work is done there.
@ -978,23 +990,28 @@ A recommended work cycle for a "project lead" is like this:
repository. repository.
(4) "git repack" the public repository. This establishes a big (4) "git repack" the public repository. This establishes a big
pack that contains the initial set of objects. pack that contains the initial set of objects as the
baseline, and possibly "git prune-packed" if the transport
used for pulling from your repository supports packed
repositories.
(5) Keep working in your primary repository, and push your (5) Keep working in your primary repository. Your changes
changes to the public repository. Your changes include include modifications of your own, patches you receive via
your own, patches you receive via e-mail, and merge resulting e-mails, and merges resulting from pulling the "public"
from pulling the "public" repositories of your "subsystem repositories of your "subsystem maintainers".
maintainers".
You can repack this private repository whenever you feel You can repack this private repository whenever you feel
like. like.
(6) Every once in a while, "git repack" the public repository. (6) Push your changes to the public repository, and announce it
to the public.
(7) Every once in a while, "git repack" the public repository.
Go back to step (5) and continue working. Go back to step (5) and continue working.
A recommended work cycle for a "subsystem maintainer" that
works on that project and has own "public repository" is like A recommended work cycle for a "subsystem maintainer" that works
this: on that project and has own "public repository" goes like this:
(1) Prepare your work repository, by "git clone" the public (1) Prepare your work repository, by "git clone" the public
repository of the "project lead". repository of the "project lead".
@ -1006,21 +1023,27 @@ this:
currently not automated. currently not automated.
(4) Push into the public repository from your primary (4) Push into the public repository from your primary
repository. repository. Run "git repack" (and possibly "git
prune-packed" if the transport used for pulling from your
repository supports packed repositories.
(5) Keep working in your primary repository, and push your (5) Keep working in your primary repository. Your changes
changes to your public repository, and ask your "project include modifications of your own, patches you receive via
lead" to pull from it. Your changes include your own, e-mails, and merges resulting from pulling the "public"
patches you receive via e-mail, and merge resulting from repositories of your "project lead" and possibly your
pulling the "public" repositories of your "project lead" "sub-subsystem maintainers".
and possibly your "sub-subsystem maintainers".
You can repack this private repository whenever you feel You can repack this private repository whenever you feel
like. like.
(6) Every once in a while, "git repack" the public repository. (6) Push your changes to your public repository, and ask your
"project lead" and possibly your "sub-subsystem
maintainers" to pull from it.
(7) Every once in a while, "git repack" the public repository.
Go back to step (5) and continue working. Go back to step (5) and continue working.
A recommended work cycle for an "individual developer" who does A recommended work cycle for an "individual developer" who does
not have a "public" repository is somewhat different. It goes not have a "public" repository is somewhat different. It goes
like this: like this: