{"thread":{"id":"39439","subject":"[PATCHv3] submodule documentation: Reorder introductory paragraphs","startedAt":"2015-05-27T19:48:01Z","lastAt":"2015-05-27T19:48:01Z","messageCount":1,"participants":["Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"262254","messageId":"1432756081-31180-1-git-send-email-sbeller@google.com","threadId":"39439","inReplyTo":null,"subject":"[PATCHv3] submodule documentation: Reorder introductory paragraphs","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-05-27T19:48:01Z","receivedAt":"2015-05-27T19:48:01Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"It's better to start the man page with a description of what submodules\nactually are instead of saying what they are not.\n\nReorder the paragraphs such that\nthe first short paragraph introduces the submodule concept,\nthe second paragraph highlights the usage of the submodule command,\nthe third paragraph giving background information,\nand finally the fourth paragraph discusing alternatives such\nas subtrees and remotes, which we don't want to be confused with.\n\nThis ordering deepens the knowledge on submodules with each paragraph.\nFirst the basic questions like \"How/what\" will be answered, while the\nunderlying concepts will be taught at a later time.\n\nMaking sure it is not confused with subtrees and remotes is not really\nenhancing knowledge of submodules itself, but rather painting the big\npicture of git concepts, so you could also argue to have it as the second\nparagraph. Personally I think this may confuse readers, specially\nnewcomers though.\n\nAdditionally to reordering the paragraphs, they have been slightly\nreworded.\n\nSigned-off-by: Stefan Beller <sbeller@google.com>\n---\n\nI think this is the best I can come up with for now.\n* It still mentions the remotes as a potential explanation mud-hole, but I feel\n  it helps the reader understand submodules a little better.\n* We also start with a typical git man page intro (Dropping \"This command does ...\")\n\n Documentation/git-submodule.txt | 50 ++++++++++++++++++-----------------------\n 1 file changed, 22 insertions(+), 28 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 2c25916..2ca1391 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -25,22 +25,17 @@ SYNOPSIS\n \n DESCRIPTION\n -----------\n-Submodules allow foreign repositories to be embedded within\n-a dedicated subdirectory of the source tree, always pointed\n-at a particular commit.\n+Inspects, updates and manages submodules.\n \n-They are not to be confused with remotes, which are meant mainly\n-for branches of the same project; submodules are meant for\n-different projects you would like to make part of your source tree,\n-while the history of the two projects still stays completely\n-independent and you cannot modify the contents of the submodule\n-from within the main project.\n-If you want to merge the project histories and want to treat the\n-aggregated whole as a single project from then on, you may want to\n-add a remote for the other project and use the 'subtree' merge strategy,\n-instead of treating the other project as a submodule. Directories\n-that come from both projects can be cloned and checked out as a whole\n-if you choose to go that route.\n+A Submodule allows you to keep another Git repository in a subdirectory\n+of your repository. The other repository has its own history, which does not\n+interfere with the history of the current repository. This can be used to\n+have external dependencies such as third party libraries for example.\n+\n+When cloning or pulling a repository containing submodules however,\n+these will not be checked out by default; the 'init' and 'update'\n+subcommands will maintain submodules checked out and at\n+appropriate revision in your working tree.\n \n Submodules are composed from a so-called `gitlink` tree entry\n in the main repository that refers to a particular commit object\n@@ -51,19 +46,18 @@ describes the default URL the submodule shall be cloned from.\n The logical name can be used for overriding this URL within your\n local repository configuration (see 'submodule init').\n \n-This command will manage the tree entries and contents of the\n-gitmodules file for you, as well as inspect the status of your\n-submodules and update them.\n-When adding a new submodule to the tree, the 'add' subcommand\n-is to be used.  However, when pulling a tree containing submodules,\n-these will not be checked out by default;\n-the 'init' and 'update' subcommands will maintain submodules\n-checked out and at appropriate revision in your working tree.\n-You can briefly inspect the up-to-date status of your submodules\n-using the 'status' subcommand and get a detailed overview of the\n-difference between the index and checkouts using the 'summary'\n-subcommand.\n-\n+Submodules are not to be confused with remotes, which are other\n+repositories of the same project; submodules are meant for\n+different projects you would like to make part of your source tree,\n+while the history of the two projects still stays completely\n+independent and you cannot modify the contents of the submodule\n+from within the main project.\n+If you want to merge the project histories and want to treat the\n+aggregated whole as a single project from then on, you may want to\n+add a remote for the other project and use the 'subtree' merge strategy,\n+instead of treating the other project as a submodule. Directories\n+that come from both projects can be cloned and checked out as a whole\n+if you choose to go that route.\n \n COMMANDS\n --------\n-- \n2.4.1.345.gab207b6.dirty\n"}]}