{"thread":{"id":"1256","subject":"[PATCH] Documentation: update recommended workflow when working with others.","startedAt":"2005-07-16T03:56:12Z","lastAt":"2005-07-16T04:39:22Z","messageCount":2,"participants":["Junio C Hamano","randy_dunlap"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"6183","messageId":"7vslyfo143.fsf@assigned-by-dhcp.cox.net","threadId":"1256","inReplyTo":null,"subject":"[PATCH] Documentation: update recommended workflow when working with others.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-16T03:56:12Z","receivedAt":"2005-07-16T03:56:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Clarify that the hierarchy implied by the recommended workflow\nis only informal.\n\nRefer readers to nice illustration by Rundy Dunlap.\n\nSeparate out the step to \"push\" to own public repository in the\nworkflow.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Documentation/tutorial.txt |   65 ++++++++++++++++++++++++++++++--------------\n 1 files changed, 44 insertions(+), 21 deletions(-)\n\n70a7f8c18de2006a500059f3cb23d353250d0a9d\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -967,7 +967,19 @@ unpacked in the destination, unless rsyn\n \tWorking with Others\n \t-------------------\n \n-A recommended work cycle for a \"project lead\" is like this:\n+Although git is a truly distributed system, it is often\n+convenient to organize your project with an informal hierarchy\n+of developers.  Linux kernel development is run this way.  There\n+is a nice illustration (page 17, \"Merges to Mainline\") in Rundy\n+Dunlap's presentation (http://tinyurl.com/a2jdg).\n+\n+It should be stressed that this hierarchy is purely \"informal\".\n+There is nothing fundamental in git that enforces the \"chain of\n+patch flow\" this hierarchy implies.  You do not have to pull\n+from only one remote repository.\n+\n+\n+A recommended workflow for a \"project lead\" goes like this:\n \n  (1) Prepare your primary repository on your local machine. Your\n      work is done there.\n@@ -978,23 +990,28 @@ A recommended work cycle for a \"project \n      repository.\n \n  (4) \"git repack\" the public repository.  This establishes a big\n-     pack that contains the initial set of objects.\n-\n- (5) Keep working in your primary repository, and push your\n-     changes to the public repository.  Your changes include\n-     your own, patches you receive via e-mail, and merge resulting\n-     from pulling the \"public\" repositories of your \"subsystem\n-     maintainers\".\n+     pack that contains the initial set of objects as the\n+     baseline, and possibly \"git prune-packed\" if the transport\n+     used for pulling from your repository supports packed\n+     repositories.\n+\n+ (5) Keep working in your primary repository.  Your changes\n+     include modifications of your own, patches you receive via\n+     e-mails, and merges resulting from pulling the \"public\"\n+     repositories of your \"subsystem maintainers\".\n \n      You can repack this private repository whenever you feel\n      like.\n \n- (6) Every once in a while, \"git repack\" the public repository.\n+ (6) Push your changes to the public repository, and announce it\n+     to the public.\n+\n+ (7) Every once in a while, \"git repack\" the public repository.\n      Go back to step (5) and continue working.\n \n-A recommended work cycle for a \"subsystem maintainer\" that\n-works on that project and has own \"public repository\" is like\n-this:\n+\n+A recommended work cycle for a \"subsystem maintainer\" that works\n+on that project and has own \"public repository\" goes like this:\n \n  (1) Prepare your work repository, by \"git clone\" the public\n      repository of the \"project lead\".\n@@ -1006,21 +1023,27 @@ this:\n      currently not automated.\n \n  (4) Push into the public repository from your primary\n-     repository.\n-\n- (5) Keep working in your primary repository, and push your\n-     changes to your public repository, and ask your \"project\n-     lead\" to pull from it.  Your changes include your own,\n-     patches you receive via e-mail, and merge resulting from\n-     pulling the \"public\" repositories of your \"project lead\"\n-     and possibly your \"sub-subsystem maintainers\".\n+     repository.  Run \"git repack\" (and possibly \"git\n+     prune-packed\" if the transport used for pulling from your\n+     repository supports packed repositories.\n+\n+ (5) Keep working in your primary repository.  Your changes\n+     include modifications of your own, patches you receive via\n+     e-mails, and merges resulting from pulling the \"public\"\n+     repositories of your \"project lead\" and possibly your\n+     \"sub-subsystem maintainers\".\n \n      You can repack this private repository whenever you feel\n      like.\n \n- (6) Every once in a while, \"git repack\" the public repository.\n+ (6) Push your changes to your public repository, and ask your\n+     \"project lead\" and possibly your \"sub-subsystem\n+     maintainers\" to pull from it.\n+\n+ (7) Every once in a while, \"git repack\" the public repository.\n      Go back to step (5) and continue working.\n \n+\n A recommended work cycle for an \"individual developer\" who does\n not have a \"public\" repository is somewhat different.  It goes\n like this:\n"},{"id":"6184","messageId":"20050715213922.66414ac5.rdunlap@xenotime.net","threadId":"1256","inReplyTo":"7vslyfo143.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: update recommended workflow when working with others.","fromName":"randy_dunlap","fromEmail":"rdunlap@xenotime.net","sentAt":"2005-07-16T04:39:22Z","receivedAt":"2005-07-16T04:39:22Z","isPatch":true,"sender":{"key":"rdunlap@xenotime.net","avatar":null},"body":"On Fri, 15 Jul 2005 20:56:12 -0700 Junio C Hamano wrote:\n\n> Clarify that the hierarchy implied by the recommended workflow\n> is only informal.\n> \n> Refer readers to nice illustration by Rundy Dunlap.\n                                        Randy            (please)\n\n> \n> Separate out the step to \"push\" to own public repository in the\n> workflow.\n> \n> Signed-off-by: Junio C Hamano <junkio@cox.net>\n> ---\n> \n>  Documentation/tutorial.txt |   65 ++++++++++++++++++++++++++++++--------------\n>  1 files changed, 44 insertions(+), 21 deletions(-)\n> \n> 70a7f8c18de2006a500059f3cb23d353250d0a9d\n> diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\n> --- a/Documentation/tutorial.txt\n> +++ b/Documentation/tutorial.txt\n> @@ -967,7 +967,19 @@ unpacked in the destination, unless rsyn\n>  \tWorking with Others\n>  \t-------------------\n>  \n> -A recommended work cycle for a \"project lead\" is like this:\n> +Although git is a truly distributed system, it is often\n> +convenient to organize your project with an informal hierarchy\n> +of developers.  Linux kernel development is run this way.  There\n> +is a nice illustration (page 17, \"Merges to Mainline\") in Rundy\n> +Dunlap's presentation (http://tinyurl.com/a2jdg).\n\nand again.  :)\n\nThanks,\n---\n~Randy\n"}]}