{"thread":{"id":"32991","subject":"[PATCH 00/13] Git help option to list user guides","startedAt":"2013-02-23T23:05:48Z","lastAt":"2013-02-26T20:24:45Z","messageCount":37,"participants":["Philip Oakley","David Aguilar","Junio C Hamano","W. Trevor King"],"isPatch":true,"patchVersion":1,"patchTotal":13},"messages":[{"id":"210115","messageId":"1361660761-1932-1-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":null,"subject":"[PATCH 00/13] Git help option to list user guides","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:48Z","receivedAt":"2013-02-23T23:05:48Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"The git help system will list common commands, and all commands\nif asked. However it is difficult for newer users to discover the\nguides that are available. This series seeks to add such an option\nto 'git help', and allow the user-manual and [git]everyday to be\naccessed in the same way.\n\nPatch 1 to 7 update the codebase and look to work correctly.\nPatch 1 & 3 are tidy ups. \nThe code is very strongly based on the existing common-commands\nlist so could be refactored and joined if the series is accepted.\n\nPatch 8 onward get into areas of the documentation Makefile that I\nneed help on so that the user-manual and [git]everyday can \nfollow the naming convention for guides and be picked up by the code.\nThe intent is shown, but the Documentation/Makefile fails for the\nrenamed gituser-manual and giteveryday - advice needed.\n\nI'm minded to make them have a man page format to simplify changes to\nthe make file but haven't managed to get that format right. The\nalternative is to tweak the make file to cope with these 'pretty'\ndocuments yet still move them to their new names. (I'm unfamiliar\nwith make files)\n\nHolding pages have been created for the vacated page locations in\nthe same vein as used for Rename {git- => git}remote-helpers.txt\n\nThe patches are built upon V1.8.2-rc0 which includes the recent\nuser-manual changes.\n\nInitial discussion was at $gmane/215814/focus=216146\n\nPhilip Oakley (13):\n Use 'Git' in help messages\n Show 'git help ' usage, with examples\n Help.c use OPT_COUNTUP\n Help.c add --guide option\n Help.c: add list_common_guides_help() function\n Add guide-list.txt and extraction shell\n Extend name string for longer names\n Rename user-manual to gituser-manual\n Rename everyday to giteveryday\n Update Git(1) links to guides\n Add missing guides to list and regenerate\n Documentation/Makefile: update git guide links\n Fixup! doc: giteveryday and user-manual man format\n\n Documentation/Makefile | 4 +\n Documentation/everyday.txt | 424 +---\n Documentation/git.txt | 12 +-\n Documentation/giteveryday.txt | 419 ++++\n Documentation/gituser-manual.txt | 4639 +++++++++++++++++++++++++++++++++++++\n Documentation/user-manual.txt | 4643 +-------------------------------------\n builtin/help.c | 11 +-\n common-guides.h | 15 +\n generate-cmdlist.sh | 2 +-\n generate-guidelist.sh | 23 +\n git.c | 4 +-\n guide-list.txt | 30 +\n help.c | 30 +-\n help.h | 1 +\n 14 files changed, 5208 insertions(+), 5049 deletions(-)\n create mode 100644 Documentation/giteveryday.txt\n create mode 100644 Documentation/gituser-manual.txt\n create mode 100644 common-guides.h\n create mode 100644 generate-guidelist.sh\n create mode 100644 guide-list.txt\n\n-- \n1.8.1.msysgit.1\n"},{"id":"210117","messageId":"1361660761-1932-2-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 01/13] Use 'Git' in help messages","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:49Z","receivedAt":"2013-02-23T23:05:49Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Signed-off-by: Philip Oakley \n---\n help.c | 12 ++++++------\n 1 file changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/help.c b/help.c\nindex 1dfa0b0..1c0e17d 100644\n--- a/help.c\n+++ b/help.c\n@@ -209,14 +209,14 @@ void list_commands(unsigned int colopts,\n {\n \tif (main_cmds->cnt) {\n \t\tconst char *exec_path = git_exec_path();\n-\t\tprintf_ln(_(\"available git commands in '%s'\"), exec_path);\n+\t\tprintf_ln(_(\"available Git commands in '%s'\"), exec_path);\n \t\tputchar('\\n');\n \t\tpretty_print_string_list(main_cmds, colopts);\n \t\tputchar('\\n');\n \t}\n \n \tif (other_cmds->cnt) {\n-\t\tprintf_ln(_(\"git commands available from elsewhere on your $PATH\"));\n+\t\tprintf_ln(_(\"Git commands available from elsewhere on your $PATH\"));\n \t\tputchar('\\n');\n \t\tpretty_print_string_list(other_cmds, colopts);\n \t\tputchar('\\n');\n@@ -232,7 +232,7 @@ void list_common_cmds_help(void)\n \t\t\tlongest = strlen(common_cmds[i].name);\n \t}\n \n-\tputs(_(\"The most commonly used git commands are:\"));\n+\tputs(_(\"The most commonly used Git commands are:\"));\n \tfor (i = 0; i < ARRAY_SIZE(common_cmds); i++) {\n \t\tprintf(\" %s \", common_cmds[i].name);\n \t\tmput_char(' ', longest - strlen(common_cmds[i].name));\n@@ -289,7 +289,7 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)\n #define SIMILAR_ENOUGH(x) ((x) < SIMILARITY_FLOOR)\n \n static const char bad_interpreter_advice[] =\n-\tN_(\"'%s' appears to be a git command, but we were not\\n\"\n+\tN_(\"'%s' appears to be a Git command, but we were not\\n\"\n \t\"able to execute it. Maybe git-%s is broken?\");\n \n const char *help_unknown_cmd(const char *cmd)\n@@ -380,7 +380,7 @@ const char *help_unknown_cmd(const char *cmd)\n \t\treturn assumed;\n \t}\n \n-\tfprintf_ln(stderr, _(\"git: '%s' is not a git command. See 'git --help'.\"), cmd);\n+\tfprintf_ln(stderr, _(\"git: '%s' is not a Git command. See 'git --help'.\"), cmd);\n \n \tif (SIMILAR_ENOUGH(best_similarity)) {\n \t\tfprintf_ln(stderr,\n@@ -397,6 +397,6 @@ const char *help_unknown_cmd(const char *cmd)\n \n int cmd_version(int argc, const char **argv, const char *prefix)\n {\n-\tprintf(\"git version %s\\n\", git_version_string);\n+\tprintf(\"Git version %s\\n\", git_version_string);\n \treturn 0;\n }\n-- \n1.8.1.msysgit.1\n"},{"id":"210116","messageId":"1361660761-1932-3-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 02/13] Show 'git help ' usage, with examples","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:50Z","receivedAt":"2013-02-23T23:05:50Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"The git(1) man page must be accessed via 'git help git' on Git for Windows\nas it has no 'man' command. And it prompts users to read the git(1) page,\nrather than hoping they follow a subsidiary link within another documentation\npage. The 'tutorial' is an obvious guide to suggest.\n\nSigned-off-by: Philip Oakley \n---\n git.c | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/git.c b/git.c\nindex b10c18b..bf0e0de 100644\n--- a/git.c\n+++ b/git.c\n@@ -13,7 +13,9 @@ const char git_usage_string[] =\n \t\" []\";\n \n const char git_more_info_string[] =\n-\tN_(\"See 'git help ' for more information on a specific command.\");\n+\tN_(\"See 'git help ' for more information on a specific command.\\n\"\n+\t \"While 'git help ', will show the selected Git concept guide.\\n\"\n+\t \"Examples: 'git help git', 'git help branch', 'git help tutorial'..\");\n \n static struct startup_info git_startup_info;\n static int use_pager = -1;\n-- \n1.8.1.msysgit.1\n"},{"id":"210118","messageId":"1361660761-1932-4-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 03/13] Help.c use OPT_COUNTUP","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:51Z","receivedAt":"2013-02-23T23:05:51Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"rename deprecated option in preparation for 'git help --guides'.\n\nSigned-off-by: Philip Oakley \n---\n builtin/help.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/builtin/help.c b/builtin/help.c\nindex d1d7181..d10cbed 100644\n--- a/builtin/help.c\n+++ b/builtin/help.c\n@@ -39,7 +39,7 @@ static int show_all = 0;\n static unsigned int colopts;\n static enum help_format help_format = HELP_FORMAT_NONE;\n static struct option builtin_help_options[] = {\n-\tOPT_BOOLEAN('a', \"all\", &show_all, N_(\"print all available commands\")),\n+\tOPT_COUNTUP('a', \"all\", &show_all, N_(\"print all available commands\")),\n \tOPT_SET_INT('m', \"man\", &help_format, N_(\"show man page\"), HELP_FORMAT_MAN),\n \tOPT_SET_INT('w', \"web\", &help_format, N_(\"show manual in web browser\"),\n \t\t\tHELP_FORMAT_WEB),\n-- \n1.8.1.msysgit.1\n"},{"id":"210119","messageId":"1361660761-1932-5-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 04/13] Help.c add --guide option","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:52Z","receivedAt":"2013-02-23T23:05:52Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Logic, but no actions, included.\n\nSigned-off-by: Philip Oakley \n---\n builtin/help.c | 8 ++++++--\n 1 file changed, 6 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/help.c b/builtin/help.c\nindex d10cbed..699e679 100644\n--- a/builtin/help.c\n+++ b/builtin/help.c\n@@ -36,10 +36,12 @@ enum help_format {\n static const char *html_path;\n \n static int show_all = 0;\n+static int show_guides = 0;\n static unsigned int colopts;\n static enum help_format help_format = HELP_FORMAT_NONE;\n static struct option builtin_help_options[] = {\n \tOPT_COUNTUP('a', \"all\", &show_all, N_(\"print all available commands\")),\n+\tOPT_COUNTUP('g', \"guides\", &show_guides, N_(\"print all available guides\")),\n \tOPT_SET_INT('m', \"man\", &help_format, N_(\"show man page\"), HELP_FORMAT_MAN),\n \tOPT_SET_INT('w', \"web\", &help_format, N_(\"show manual in web browser\"),\n \t\t\tHELP_FORMAT_WEB),\n@@ -49,7 +51,7 @@ static struct option builtin_help_options[] = {\n };\n \n static const char * const builtin_help_usage[] = {\n-\tN_(\"git help [--all] [--man|--web|--info] [command]\"),\n+\tN_(\"git help [--all] [--guides] [--man|--web|--info] [command]\"),\n \tNULL\n };\n \n@@ -429,9 +431,11 @@ int cmd_help(int argc, const char **argv, const char *prefix)\n \t\tprintf(_(\"usage: %s%s\"), _(git_usage_string), \"\\n\\n\");\n \t\tlist_commands(colopts, &main_cmds, &other_cmds);\n \t\tprintf(\"%s\\n\", _(git_more_info_string));\n+\t\tif (!show_guides) return 0;\n+\t}\n+\tif (show_guides) {\n \t\treturn 0;\n \t}\n-\n \tif (!argv[0]) {\n \t\tprintf(_(\"usage: %s%s\"), _(git_usage_string), \"\\n\\n\");\n \t\tlist_common_cmds_help();\n-- \n1.8.1.msysgit.1\n"},{"id":"210120","messageId":"1361660761-1932-6-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 05/13] Help.c: add list_common_guides_help() function","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:53Z","receivedAt":"2013-02-23T23:05:53Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Re-use list_common_cmds_help but simply change the array name.\nCandidate for future refactoring to pass a pointer to the array.\n\nDo not list User-manual and Everday Git which not follow the naming\nconvention, nor gitrepository-layout which doesn't fit within the name field size\n\nSigned-off-by: Philip Oakley \n---\n builtin/help.c | 1 +\n common-guides.h | 12 ++++++++++++\n help.c | 18 ++++++++++++++++++\n help.h | 1 +\n 4 files changed, 32 insertions(+)\n create mode 100644 common-guides.h\n\ndiff --git a/builtin/help.c b/builtin/help.c\nindex 699e679..b0746af 100644\n--- a/builtin/help.c\n+++ b/builtin/help.c\n@@ -434,6 +434,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)\n \t\tif (!show_guides) return 0;\n \t}\n \tif (show_guides) {\n+\t\tlist_common_guides_help();\n \t\treturn 0;\n \t}\n \tif (!argv[0]) {\ndiff --git a/common-guides.h b/common-guides.h\nnew file mode 100644\nindex 0000000..a8ad8d1\n--- /dev/null\n+++ b/common-guides.h\n@@ -0,0 +1,12 @@\n+/* Automatically generated by ./generate-guidelist.sh */\n+/* re-use struct cmdname_help in common-commands.h */\n+\n+static struct cmdname_help common_guides[] = {\n+ {\"attributes\", \"defining attributes per path\"},\n+ {\"glossary\", \"A GIT Glossary\"},\n+ {\"ignore\", \"Specifies intentionally untracked files to ignore\"},\n+ {\"modules\", \"defining submodule properties\"},\n+ {\"revisions\", \"specifying revisions and ranges for git\"},\n+ {\"tutorial\", \"A tutorial introduction to git (for version 1.5.1 or newer)\"},\n+ {\"workflows\", \"An overview of recommended workflows with git\"},\n+};\ndiff --git a/help.c b/help.c\nindex 1c0e17d..94df446 100644\n--- a/help.c\n+++ b/help.c\n@@ -4,6 +4,7 @@\n #include \"levenshtein.h\"\n #include \"help.h\"\n #include \"common-cmds.h\"\n+#include \"common-guides.h\"\n #include \"string-list.h\"\n #include \"column.h\"\n #include \"version.h\"\n@@ -240,6 +241,23 @@ void list_common_cmds_help(void)\n \t}\n }\n \n+void list_common_guides_help(void)\n+{\n+\tint i, longest = 0;\n+\n+\tfor (i = 0; i < ARRAY_SIZE(common_guides); i++) {\n+\t\tif (longest < strlen(common_guides[i].name))\n+\t\t\tlongest = strlen(common_guides[i].name);\n+\t}\n+\n+\tputs(_(\"The common Git guides are:\"));\n+\tfor (i = 0; i < ARRAY_SIZE(common_guides); i++) {\n+\t\tprintf(\" %s \", common_guides[i].name);\n+\t\tmput_char(' ', longest - strlen(common_guides[i].name));\n+\t\tputs(_(common_guides[i].help));\n+\t}\n+}\n+\n int is_in_cmdlist(struct cmdnames *c, const char *s)\n {\n \tint i;\ndiff --git a/help.h b/help.h\nindex 0ae5a12..4ae1fd7 100644\n--- a/help.h\n+++ b/help.h\n@@ -17,6 +17,7 @@ static inline void mput_char(char c, unsigned int num)\n }\n \n extern void list_common_cmds_help(void);\n+extern void list_common_guides_help(void);\n extern const char *help_unknown_cmd(const char *cmd);\n extern void load_command_list(const char *prefix,\n \t\t\t struct cmdnames *main_cmds,\n-- \n1.8.1.msysgit.1\n"},{"id":"210121","messageId":"1361660761-1932-7-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 06/13] Add guide-list.txt and extraction shell","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:54Z","receivedAt":"2013-02-23T23:05:54Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"The guide-list.txt uses exactly the same format as command-list.txt\nso could be merged as part of a refactoring.\n\nThe category naming for each guide is an initial suggestion and\nis not yet used. Only those with the 'guide' prefix are copied\nby the generate-guidelist.sh into the common-guides.h file.\n\nThe user-manual.txt and everyday.txt do not have the correct filename\nformat yet. And gitrepository-layout.txt name is too long to include.\nSo comment them out.\n\nSigned-off-by: Philip Oakley \n---\nThe shell script function N_() does not appear to work correctly on my\nUbuntu lash-up, so an simpler script line is used with the original\ncommented out.\n---\n generate-guidelist.sh | 23 +++++++++++++++++++++++\n guide-list.txt | 29 +++++++++++++++++++++++++++++\n 2 files changed, 52 insertions(+)\n create mode 100644 generate-guidelist.sh\n create mode 100644 guide-list.txt\n\ndiff --git a/generate-guidelist.sh b/generate-guidelist.sh\nnew file mode 100644\nindex 0000000..c0c98eb\n--- /dev/null\n+++ b/generate-guidelist.sh\n@@ -0,0 +1,23 @@\n+#!/bin/sh\n+# Usage: ./generate-guidelist.sh >>common-guides.h\n+# based on generate-cmdlist.sh\n+echo \"/* Automatically generated by $0 */\n+/* re-use struct cmdname_help in common-commands.h */\n+\n+static struct cmdname_help common_guides[] = {\"\n+\n+sed -n -e 's/^git\\([^ \t]*\\)[ \t].* guide.*/\\1/p' guide-list.txt |\n+sort |\n+while read guide\n+do\n+ sed -n '\n+ /^NAME/,/git'\"$guide\"'/H\n+ ${\n+\t x\n+#\t s/.*git'\"$guide\"' - \\(.*\\)/ {\"'\"$guide\"'\", N_(\"\\1\")},/\n+\t s/.*git'\"$guide\"' - \\(.*\\)/ {\"'\"$guide\"'\", \"\\1\"},/\n+\t p\n+ }' \"Documentation/git$guide.txt\"\n+done\n+echo \"};\"\n+\ndiff --git a/guide-list.txt b/guide-list.txt\nnew file mode 100644\nindex 0000000..a419ac4\n--- /dev/null\n+++ b/guide-list.txt\n@@ -0,0 +1,29 @@\n+# List of known git guides.\n+# guide name\t\t\t\tcategory [deprecated] [common] [guide]\n+gitattributes concept\t guide\n+gitcore-tutorial specialist\n+gitcredentials specialist\n+gitcvs-migration specialist\n+gitdiffcore specialist\n+gitglossary reference\t guide\n+githooks specialist\n+gitignore concept\t guide\n+gitmodules concept\t guide\n+gitnamespaces specialist\n+#gitrepository-layout reference guide\n+gitrevisions concept\t guide\n+gittutorial user\t guide\n+gittutorial-2 user\n+gitweb.conf specialist\n+gitweb specialist\n+gitworkflows user\t guide\n+\n+#giteveryday user\t guide\n+#gituser-manual user\t guide\n+\n+# could embed inside common-cmds.h with [guide] as the second thing,\n+# making the sed's in generate-cmdlist.sh more obvious\n+# but drop the dash in 's/^git-\\\n+\n+#gitrepository-layout is too long for the current char[16]\n+#\n-- \n1.8.1.msysgit.1\n"},{"id":"210122","messageId":"1361660761-1932-8-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 07/13] Extend name string for longer names","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:55Z","receivedAt":"2013-02-23T23:05:55Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Signed-off-by: Philip Oakley \n---\n generate-cmdlist.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/generate-cmdlist.sh b/generate-cmdlist.sh\nindex 9a4c9b9..c25561f 100755\n--- a/generate-cmdlist.sh\n+++ b/generate-cmdlist.sh\n@@ -2,7 +2,7 @@\n \n echo \"/* Automatically generated by $0 */\n struct cmdname_help {\n- char name[16];\n+ char name[20];\n char help[80];\n };\n \n-- \n1.8.1.msysgit.1\n"},{"id":"210126","messageId":"1361660761-1932-10-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 09/13] Rename everyday to giteveryday","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:57Z","receivedAt":"2013-02-23T23:05:57Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"and leave a 'page has moved' page.\n\nSigned-off-by: Philip Oakley \n---\n Documentation/everyday.txt | 424 ++----------------------------------------\n Documentation/giteveryday.txt | 413 ++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 431 insertions(+), 406 deletions(-)\n create mode 100644 Documentation/giteveryday.txt\n\ndiff --git a/Documentation/everyday.txt b/Documentation/everyday.txt\nindex e1fba85..3fc69f6 100644\n--- a/Documentation/everyday.txt\n+++ b/Documentation/everyday.txt\n@@ -1,413 +1,25 @@\n-Everyday Git With 20 Commands Or So\n+Everyday GIT With 20 Commands Or So\n ===================================\n \n-<> commands are essential for\n-anybody who makes a commit, even for somebody who works alone.\n+NAME\n+----\n+everyday - obsoleted page\n \n-If you work with other people, you will need commands listed in\n-the <> section as well.\n+SYNOPSIS\n+--------\n+See linkgit:giteveryday.\n \n-People who play the <> role need to learn some more\n-commands in addition to the above.\n+DESCRIPTION\n+-----------\n+This document has been moved to linkgit:giteveryday.\n \n-<> commands are for system\n-administrators who are responsible for the care and feeding\n-of Git repositories.\n+Please let the owners of the referring site know so that they can update the\n+link you clicked to get here.\n \n+SEE ALSO\n+--------\n+linkgit:giteveryday\n \n-Individual Developer (Standalone)[[Individual Developer (Standalone)]]\n-----------------------------------------------------------------------\n-\n-A standalone individual developer does not exchange patches with\n-other people, and works alone in a single repository, using the\n-following commands.\n-\n- * linkgit:git-init[1] to create a new repository.\n-\n- * linkgit:git-show-branch[1] to see where you are.\n-\n- * linkgit:git-log[1] to see what happened.\n-\n- * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch\n- branches.\n-\n- * linkgit:git-add[1] to manage the index file.\n-\n- * linkgit:git-diff[1] and linkgit:git-status[1] to see what\n- you are in the middle of doing.\n-\n- * linkgit:git-commit[1] to advance the current branch.\n-\n- * linkgit:git-reset[1] and linkgit:git-checkout[1] (with\n- pathname parameters) to undo changes.\n-\n- * linkgit:git-merge[1] to merge between local branches.\n-\n- * linkgit:git-rebase[1] to maintain topic branches.\n-\n- * linkgit:git-tag[1] to mark known point.\n-\n-Examples\n-~~~~~~~~\n-\n-Use a tarball as a starting point for a new repository.::\n-+\n-------------\n-$ tar zxf frotz.tar.gz\n-$ cd frotz\n-$ git init\n-$ git add . <1>\n-$ git commit -m \"import of frotz source tree.\"\n-$ git tag v2.43 <2>\n-------------\n-+\n-<1> add everything under the current directory.\n-<2> make a lightweight, unannotated tag.\n-\n-Create a topic branch and develop.::\n-+\n-------------\n-$ git checkout -b alsa-audio <1>\n-$ edit/compile/test\n-$ git checkout -- curses/ux_audio_oss.c <2>\n-$ git add curses/ux_audio_alsa.c <3>\n-$ edit/compile/test\n-$ git diff HEAD <4>\n-$ git commit -a -s <5>\n-$ edit/compile/test\n-$ git reset --soft HEAD^ <6>\n-$ edit/compile/test\n-$ git diff ORIG_HEAD <7>\n-$ git commit -a -c ORIG_HEAD <8>\n-$ git checkout master <9>\n-$ git merge alsa-audio <10>\n-$ git log --since='3 days ago' <11>\n-$ git log v2.43.. curses/ <12>\n-------------\n-+\n-<1> create a new topic branch.\n-<2> revert your botched changes in `curses/ux_audio_oss.c`.\n-<3> you need to tell Git if you added a new file; removal and\n-modification will be caught if you do `git commit -a` later.\n-<4> to see what changes you are committing.\n-<5> commit everything as you have tested, with your sign-off.\n-<6> take the last commit back, keeping what is in the working tree.\n-<7> look at the changes since the premature commit we took back.\n-<8> redo the commit undone in the previous step, using the message\n-you originally wrote.\n-<9> switch to the master branch.\n-<10> merge a topic branch into your master branch.\n-<11> review commit logs; other forms to limit output can be\n-combined and include `--max-count=10` (show 10 commits),\n-`--until=2005-12-10`, etc.\n-<12> view only the changes that touch what's in `curses/`\n-directory, since `v2.43` tag.\n-\n-\n-Individual Developer (Participant)[[Individual Developer (Participant)]]\n-------------------------------------------------------------------------\n-\n-A developer working as a participant in a group project needs to\n-learn how to communicate with others, and uses these commands in\n-addition to the ones needed by a standalone developer.\n-\n- * linkgit:git-clone[1] from the upstream to prime your local\n- repository.\n-\n- * linkgit:git-pull[1] and linkgit:git-fetch[1] from \"origin\"\n- to keep up-to-date with the upstream.\n-\n- * linkgit:git-push[1] to shared repository, if you adopt CVS\n- style shared repository workflow.\n-\n- * linkgit:git-format-patch[1] to prepare e-mail submission, if\n- you adopt Linux kernel-style public forum workflow.\n-\n-Examples\n-~~~~~~~~\n-\n-Clone the upstream and work on it. Feed changes to upstream.::\n-+\n-------------\n-$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6\n-$ cd my2.6\n-$ edit/compile/test; git commit -a -s <1>\n-$ git format-patch origin <2>\n-$ git pull <3>\n-$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>\n-$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>\n-$ git reset --hard ORIG_HEAD <6>\n-$ git gc <7>\n-$ git fetch --tags <8>\n-------------\n-+\n-<1> repeat as needed.\n-<2> extract patches from your branch for e-mail submission.\n-<3> `git pull` fetches from `origin` by default and merges into the\n-current branch.\n-<4> immediately after pulling, look at the changes done upstream\n-since last time we checked, only in the\n-area we are interested in.\n-<5> fetch from a specific branch from a specific repository and merge.\n-<6> revert the pull.\n-<7> garbage collect leftover objects from reverted pull.\n-<8> from time to time, obtain official tags from the `origin`\n-and store them under `.git/refs/tags/`.\n-\n-\n-Push into another repository.::\n-+\n-------------\n-satellite$ git clone mothership:frotz frotz <1>\n-satellite$ cd frotz\n-satellite$ git config --get-regexp '^(remote|branch)\\.' <2>\n-remote.origin.url mothership:frotz\n-remote.origin.fetch refs/heads/*:refs/remotes/origin/*\n-branch.master.remote origin\n-branch.master.merge refs/heads/master\n-satellite$ git config remote.origin.push \\\n- master:refs/remotes/satellite/master <3>\n-satellite$ edit/compile/test/commit\n-satellite$ git push origin <4>\n-\n-mothership$ cd frotz\n-mothership$ git checkout master\n-mothership$ git merge satellite/master <5>\n-------------\n-+\n-<1> mothership machine has a frotz repository under your home\n-directory; clone from it to start a repository on the satellite\n-machine.\n-<2> clone sets these configuration variables by default.\n-It arranges `git pull` to fetch and store the branches of mothership\n-machine to local `remotes/origin/*` remote-tracking branches.\n-<3> arrange `git push` to push local `master` branch to\n-`remotes/satellite/master` branch of the mothership machine.\n-<4> push will stash our work away on `remotes/satellite/master`\n-remote-tracking branch on the mothership machine. You could use this\n-as a back-up method.\n-<5> on mothership machine, merge the work done on the satellite\n-machine into the master branch.\n-\n-Branch off of a specific tag.::\n-+\n-------------\n-$ git checkout -b private2.6.14 v2.6.14 <1>\n-$ edit/compile/test; git commit -a\n-$ git checkout master\n-$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |\n- git am -3 -k <2>\n-------------\n-+\n-<1> create a private branch based on a well known (but somewhat behind)\n-tag.\n-<2> forward port all changes in `private2.6.14` branch to `master` branch\n-without a formal \"merging\".\n-\n-\n-Integrator[[Integrator]]\n-------------------------\n-\n-A fairly central person acting as the integrator in a group\n-project receives changes made by others, reviews and integrates\n-them and publishes the result for others to use, using these\n-commands in addition to the ones needed by participants.\n-\n- * linkgit:git-am[1] to apply patches e-mailed in from your\n- contributors.\n-\n- * linkgit:git-pull[1] to merge from your trusted lieutenants.\n-\n- * linkgit:git-format-patch[1] to prepare and send suggested\n- alternative to contributors.\n-\n- * linkgit:git-revert[1] to undo botched commits.\n-\n- * linkgit:git-push[1] to publish the bleeding edge.\n-\n-\n-Examples\n-~~~~~~~~\n-\n-My typical Git day.::\n-+\n-------------\n-$ git status <1>\n-$ git show-branch <2>\n-$ mailx <3>\n-& s 2 3 4 5 ./+to-apply\n-& s 7 8 ./+hold-linus\n-& q\n-$ git checkout -b topic/one master\n-$ git am -3 -i -s -u ./+to-apply <4>\n-$ compile/test\n-$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>\n-$ git checkout topic/one && git rebase master <6>\n-$ git checkout pu && git reset --hard next <7>\n-$ git merge topic/one topic/two && git merge hold/linus <8>\n-$ git checkout maint\n-$ git cherry-pick master~4 <9>\n-$ compile/test\n-$ git tag -s -m \"GIT 0.99.9x\" v0.99.9x <10>\n-$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>\n-$ git push ko <12>\n-$ git push ko v0.99.9x <13>\n-------------\n-+\n-<1> see what I was in the middle of doing, if any.\n-<2> see what topic branches I have and think about how ready\n-they are.\n-<3> read mails, save ones that are applicable, and save others\n-that are not quite ready.\n-<4> apply them, interactively, with my sign-offs.\n-<5> create topic branch as needed and apply, again with my\n-sign-offs.\n-<6> rebase internal topic branch that has not been merged to the\n-master, nor exposed as a part of a stable branch.\n-<7> restart `pu` every time from the next.\n-<8> and bundle topic branches still cooking.\n-<9> backport a critical fix.\n-<10> create a signed tag.\n-<11> make sure I did not accidentally rewind master beyond what I\n-already pushed out. `ko` shorthand points at the repository I have\n-at kernel.org, and looks like this:\n-+\n-------------\n-$ cat .git/remotes/ko\n-URL: kernel.org:/pub/scm/git/git.git\n-Pull: master:refs/tags/ko-master\n-Pull: next:refs/tags/ko-next\n-Pull: maint:refs/tags/ko-maint\n-Push: master\n-Push: next\n-Push: +pu\n-Push: maint\n-------------\n-+\n-In the output from `git show-branch`, `master` should have\n-everything `ko-master` has, and `next` should have\n-everything `ko-next` has.\n-\n-<12> push out the bleeding edge.\n-<13> push the tag out, too.\n-\n-\n-Repository Administration[[Repository Administration]]\n-------------------------------------------------------\n-\n-A repository administrator uses the following tools to set up\n-and maintain access to the repository by developers.\n-\n- * linkgit:git-daemon[1] to allow anonymous download from\n- repository.\n-\n- * linkgit:git-shell[1] can be used as a 'restricted login shell'\n- for shared central repository users.\n-\n-link:howto/update-hook-example.txt[update hook howto] has a good\n-example of managing a shared central repository.\n-\n-\n-Examples\n-~~~~~~~~\n-We assume the following in /etc/services::\n-+\n-------------\n-$ grep 9418 /etc/services\n-git\t\t9418/tcp\t\t# Git Version Control System\n-------------\n-\n-Run git-daemon to serve /pub/scm from inetd.::\n-+\n-------------\n-$ grep git /etc/inetd.conf\n-git\tstream\ttcp\tnowait\tnobody \\\n- /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm\n-------------\n-+\n-The actual configuration line should be on one line.\n-\n-Run git-daemon to serve /pub/scm from xinetd.::\n-+\n-------------\n-$ cat /etc/xinetd.d/git-daemon\n-# default: off\n-# description: The Git server offers access to Git repositories\n-service git\n-{\n- disable = no\n- type = UNLISTED\n- port = 9418\n- socket_type = stream\n- wait = no\n- user = nobody\n- server = /usr/bin/git-daemon\n- server_args = --inetd --export-all --base-path=/pub/scm\n- log_on_failure += USERID\n-}\n-------------\n-+\n-Check your xinetd(8) documentation and setup, this is from a Fedora system.\n-Others might be different.\n-\n-Give push/pull only access to developers.::\n-+\n-------------\n-$ grep git /etc/passwd <1>\n-alice:x:1000:1000::/home/alice:/usr/bin/git-shell\n-bob:x:1001:1001::/home/bob:/usr/bin/git-shell\n-cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell\n-david:x:1003:1003::/home/david:/usr/bin/git-shell\n-$ grep git /etc/shells <2>\n-/usr/bin/git-shell\n-------------\n-+\n-<1> log-in shell is set to /usr/bin/git-shell, which does not\n-allow anything but `git push` and `git pull`. The users should\n-get an ssh access to the machine.\n-<2> in many distributions /etc/shells needs to list what is used\n-as the login shell.\n-\n-CVS-style shared repository.::\n-+\n-------------\n-$ grep git /etc/group <1>\n-git:x:9418:alice,bob,cindy,david\n-$ cd /home/devo.git\n-$ ls -l <2>\n- lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master\n- drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches\n- -rw-rw-r-- 1 david git 84 Dec 4 22:40 config\n- -rw-rw-r-- 1 david git 58 Dec 4 22:40 description\n- drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks\n- -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index\n- drwxrwsr-x 2 david git 4096 Dec 4 22:40 info\n- drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects\n- drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs\n- drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes\n-$ ls -l hooks/update <3>\n- -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update\n-$ cat info/allowed-users <4>\n-refs/heads/master\talice\\|cindy\n-refs/heads/doc-update\tbob\n-refs/tags/v[0-9]*\tdavid\n-------------\n-+\n-<1> place the developers into the same git group.\n-<2> and make the shared repository writable by the group.\n-<3> use update-hook example by Carl from Documentation/howto/\n-for branch policy control.\n-<4> alice and cindy can push into master, only bob can push into doc-update.\n-david is the release manager and is the only person who can\n-create and push version tags.\n-\n-HTTP server to support dumb protocol transfer.::\n-+\n-------------\n-dev$ git update-server-info <1>\n-dev$ ftp user@isp.example.com <2>\n-ftp> cp -r .git /home/user/myproject.git\n-------------\n-+\n-<1> make sure your info/refs and objects/info/packs are up-to-date\n-<2> upload to public HTTP server hosted by your ISP.\n+GIT\n+---\n+This page location is no longer a part of the linkgit:git[1] suite\ndiff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt\nnew file mode 100644\nindex 0000000..e1fba85\n--- /dev/null\n+++ b/Documentation/giteveryday.txt\n@@ -0,0 +1,413 @@\n+Everyday Git With 20 Commands Or So\n+===================================\n+\n+<> commands are essential for\n+anybody who makes a commit, even for somebody who works alone.\n+\n+If you work with other people, you will need commands listed in\n+the <> section as well.\n+\n+People who play the <> role need to learn some more\n+commands in addition to the above.\n+\n+<> commands are for system\n+administrators who are responsible for the care and feeding\n+of Git repositories.\n+\n+\n+Individual Developer (Standalone)[[Individual Developer (Standalone)]]\n+----------------------------------------------------------------------\n+\n+A standalone individual developer does not exchange patches with\n+other people, and works alone in a single repository, using the\n+following commands.\n+\n+ * linkgit:git-init[1] to create a new repository.\n+\n+ * linkgit:git-show-branch[1] to see where you are.\n+\n+ * linkgit:git-log[1] to see what happened.\n+\n+ * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch\n+ branches.\n+\n+ * linkgit:git-add[1] to manage the index file.\n+\n+ * linkgit:git-diff[1] and linkgit:git-status[1] to see what\n+ you are in the middle of doing.\n+\n+ * linkgit:git-commit[1] to advance the current branch.\n+\n+ * linkgit:git-reset[1] and linkgit:git-checkout[1] (with\n+ pathname parameters) to undo changes.\n+\n+ * linkgit:git-merge[1] to merge between local branches.\n+\n+ * linkgit:git-rebase[1] to maintain topic branches.\n+\n+ * linkgit:git-tag[1] to mark known point.\n+\n+Examples\n+~~~~~~~~\n+\n+Use a tarball as a starting point for a new repository.::\n++\n+------------\n+$ tar zxf frotz.tar.gz\n+$ cd frotz\n+$ git init\n+$ git add . <1>\n+$ git commit -m \"import of frotz source tree.\"\n+$ git tag v2.43 <2>\n+------------\n++\n+<1> add everything under the current directory.\n+<2> make a lightweight, unannotated tag.\n+\n+Create a topic branch and develop.::\n++\n+------------\n+$ git checkout -b alsa-audio <1>\n+$ edit/compile/test\n+$ git checkout -- curses/ux_audio_oss.c <2>\n+$ git add curses/ux_audio_alsa.c <3>\n+$ edit/compile/test\n+$ git diff HEAD <4>\n+$ git commit -a -s <5>\n+$ edit/compile/test\n+$ git reset --soft HEAD^ <6>\n+$ edit/compile/test\n+$ git diff ORIG_HEAD <7>\n+$ git commit -a -c ORIG_HEAD <8>\n+$ git checkout master <9>\n+$ git merge alsa-audio <10>\n+$ git log --since='3 days ago' <11>\n+$ git log v2.43.. curses/ <12>\n+------------\n++\n+<1> create a new topic branch.\n+<2> revert your botched changes in `curses/ux_audio_oss.c`.\n+<3> you need to tell Git if you added a new file; removal and\n+modification will be caught if you do `git commit -a` later.\n+<4> to see what changes you are committing.\n+<5> commit everything as you have tested, with your sign-off.\n+<6> take the last commit back, keeping what is in the working tree.\n+<7> look at the changes since the premature commit we took back.\n+<8> redo the commit undone in the previous step, using the message\n+you originally wrote.\n+<9> switch to the master branch.\n+<10> merge a topic branch into your master branch.\n+<11> review commit logs; other forms to limit output can be\n+combined and include `--max-count=10` (show 10 commits),\n+`--until=2005-12-10`, etc.\n+<12> view only the changes that touch what's in `curses/`\n+directory, since `v2.43` tag.\n+\n+\n+Individual Developer (Participant)[[Individual Developer (Participant)]]\n+------------------------------------------------------------------------\n+\n+A developer working as a participant in a group project needs to\n+learn how to communicate with others, and uses these commands in\n+addition to the ones needed by a standalone developer.\n+\n+ * linkgit:git-clone[1] from the upstream to prime your local\n+ repository.\n+\n+ * linkgit:git-pull[1] and linkgit:git-fetch[1] from \"origin\"\n+ to keep up-to-date with the upstream.\n+\n+ * linkgit:git-push[1] to shared repository, if you adopt CVS\n+ style shared repository workflow.\n+\n+ * linkgit:git-format-patch[1] to prepare e-mail submission, if\n+ you adopt Linux kernel-style public forum workflow.\n+\n+Examples\n+~~~~~~~~\n+\n+Clone the upstream and work on it. Feed changes to upstream.::\n++\n+------------\n+$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6\n+$ cd my2.6\n+$ edit/compile/test; git commit -a -s <1>\n+$ git format-patch origin <2>\n+$ git pull <3>\n+$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>\n+$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>\n+$ git reset --hard ORIG_HEAD <6>\n+$ git gc <7>\n+$ git fetch --tags <8>\n+------------\n++\n+<1> repeat as needed.\n+<2> extract patches from your branch for e-mail submission.\n+<3> `git pull` fetches from `origin` by default and merges into the\n+current branch.\n+<4> immediately after pulling, look at the changes done upstream\n+since last time we checked, only in the\n+area we are interested in.\n+<5> fetch from a specific branch from a specific repository and merge.\n+<6> revert the pull.\n+<7> garbage collect leftover objects from reverted pull.\n+<8> from time to time, obtain official tags from the `origin`\n+and store them under `.git/refs/tags/`.\n+\n+\n+Push into another repository.::\n++\n+------------\n+satellite$ git clone mothership:frotz frotz <1>\n+satellite$ cd frotz\n+satellite$ git config --get-regexp '^(remote|branch)\\.' <2>\n+remote.origin.url mothership:frotz\n+remote.origin.fetch refs/heads/*:refs/remotes/origin/*\n+branch.master.remote origin\n+branch.master.merge refs/heads/master\n+satellite$ git config remote.origin.push \\\n+ master:refs/remotes/satellite/master <3>\n+satellite$ edit/compile/test/commit\n+satellite$ git push origin <4>\n+\n+mothership$ cd frotz\n+mothership$ git checkout master\n+mothership$ git merge satellite/master <5>\n+------------\n++\n+<1> mothership machine has a frotz repository under your home\n+directory; clone from it to start a repository on the satellite\n+machine.\n+<2> clone sets these configuration variables by default.\n+It arranges `git pull` to fetch and store the branches of mothership\n+machine to local `remotes/origin/*` remote-tracking branches.\n+<3> arrange `git push` to push local `master` branch to\n+`remotes/satellite/master` branch of the mothership machine.\n+<4> push will stash our work away on `remotes/satellite/master`\n+remote-tracking branch on the mothership machine. You could use this\n+as a back-up method.\n+<5> on mothership machine, merge the work done on the satellite\n+machine into the master branch.\n+\n+Branch off of a specific tag.::\n++\n+------------\n+$ git checkout -b private2.6.14 v2.6.14 <1>\n+$ edit/compile/test; git commit -a\n+$ git checkout master\n+$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |\n+ git am -3 -k <2>\n+------------\n++\n+<1> create a private branch based on a well known (but somewhat behind)\n+tag.\n+<2> forward port all changes in `private2.6.14` branch to `master` branch\n+without a formal \"merging\".\n+\n+\n+Integrator[[Integrator]]\n+------------------------\n+\n+A fairly central person acting as the integrator in a group\n+project receives changes made by others, reviews and integrates\n+them and publishes the result for others to use, using these\n+commands in addition to the ones needed by participants.\n+\n+ * linkgit:git-am[1] to apply patches e-mailed in from your\n+ contributors.\n+\n+ * linkgit:git-pull[1] to merge from your trusted lieutenants.\n+\n+ * linkgit:git-format-patch[1] to prepare and send suggested\n+ alternative to contributors.\n+\n+ * linkgit:git-revert[1] to undo botched commits.\n+\n+ * linkgit:git-push[1] to publish the bleeding edge.\n+\n+\n+Examples\n+~~~~~~~~\n+\n+My typical Git day.::\n++\n+------------\n+$ git status <1>\n+$ git show-branch <2>\n+$ mailx <3>\n+& s 2 3 4 5 ./+to-apply\n+& s 7 8 ./+hold-linus\n+& q\n+$ git checkout -b topic/one master\n+$ git am -3 -i -s -u ./+to-apply <4>\n+$ compile/test\n+$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>\n+$ git checkout topic/one && git rebase master <6>\n+$ git checkout pu && git reset --hard next <7>\n+$ git merge topic/one topic/two && git merge hold/linus <8>\n+$ git checkout maint\n+$ git cherry-pick master~4 <9>\n+$ compile/test\n+$ git tag -s -m \"GIT 0.99.9x\" v0.99.9x <10>\n+$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>\n+$ git push ko <12>\n+$ git push ko v0.99.9x <13>\n+------------\n++\n+<1> see what I was in the middle of doing, if any.\n+<2> see what topic branches I have and think about how ready\n+they are.\n+<3> read mails, save ones that are applicable, and save others\n+that are not quite ready.\n+<4> apply them, interactively, with my sign-offs.\n+<5> create topic branch as needed and apply, again with my\n+sign-offs.\n+<6> rebase internal topic branch that has not been merged to the\n+master, nor exposed as a part of a stable branch.\n+<7> restart `pu` every time from the next.\n+<8> and bundle topic branches still cooking.\n+<9> backport a critical fix.\n+<10> create a signed tag.\n+<11> make sure I did not accidentally rewind master beyond what I\n+already pushed out. `ko` shorthand points at the repository I have\n+at kernel.org, and looks like this:\n++\n+------------\n+$ cat .git/remotes/ko\n+URL: kernel.org:/pub/scm/git/git.git\n+Pull: master:refs/tags/ko-master\n+Pull: next:refs/tags/ko-next\n+Pull: maint:refs/tags/ko-maint\n+Push: master\n+Push: next\n+Push: +pu\n+Push: maint\n+------------\n++\n+In the output from `git show-branch`, `master` should have\n+everything `ko-master` has, and `next` should have\n+everything `ko-next` has.\n+\n+<12> push out the bleeding edge.\n+<13> push the tag out, too.\n+\n+\n+Repository Administration[[Repository Administration]]\n+------------------------------------------------------\n+\n+A repository administrator uses the following tools to set up\n+and maintain access to the repository by developers.\n+\n+ * linkgit:git-daemon[1] to allow anonymous download from\n+ repository.\n+\n+ * linkgit:git-shell[1] can be used as a 'restricted login shell'\n+ for shared central repository users.\n+\n+link:howto/update-hook-example.txt[update hook howto] has a good\n+example of managing a shared central repository.\n+\n+\n+Examples\n+~~~~~~~~\n+We assume the following in /etc/services::\n++\n+------------\n+$ grep 9418 /etc/services\n+git\t\t9418/tcp\t\t# Git Version Control System\n+------------\n+\n+Run git-daemon to serve /pub/scm from inetd.::\n++\n+------------\n+$ grep git /etc/inetd.conf\n+git\tstream\ttcp\tnowait\tnobody \\\n+ /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm\n+------------\n++\n+The actual configuration line should be on one line.\n+\n+Run git-daemon to serve /pub/scm from xinetd.::\n++\n+------------\n+$ cat /etc/xinetd.d/git-daemon\n+# default: off\n+# description: The Git server offers access to Git repositories\n+service git\n+{\n+ disable = no\n+ type = UNLISTED\n+ port = 9418\n+ socket_type = stream\n+ wait = no\n+ user = nobody\n+ server = /usr/bin/git-daemon\n+ server_args = --inetd --export-all --base-path=/pub/scm\n+ log_on_failure += USERID\n+}\n+------------\n++\n+Check your xinetd(8) documentation and setup, this is from a Fedora system.\n+Others might be different.\n+\n+Give push/pull only access to developers.::\n++\n+------------\n+$ grep git /etc/passwd <1>\n+alice:x:1000:1000::/home/alice:/usr/bin/git-shell\n+bob:x:1001:1001::/home/bob:/usr/bin/git-shell\n+cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell\n+david:x:1003:1003::/home/david:/usr/bin/git-shell\n+$ grep git /etc/shells <2>\n+/usr/bin/git-shell\n+------------\n++\n+<1> log-in shell is set to /usr/bin/git-shell, which does not\n+allow anything but `git push` and `git pull`. The users should\n+get an ssh access to the machine.\n+<2> in many distributions /etc/shells needs to list what is used\n+as the login shell.\n+\n+CVS-style shared repository.::\n++\n+------------\n+$ grep git /etc/group <1>\n+git:x:9418:alice,bob,cindy,david\n+$ cd /home/devo.git\n+$ ls -l <2>\n+ lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master\n+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches\n+ -rw-rw-r-- 1 david git 84 Dec 4 22:40 config\n+ -rw-rw-r-- 1 david git 58 Dec 4 22:40 description\n+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks\n+ -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index\n+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 info\n+ drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects\n+ drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs\n+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes\n+$ ls -l hooks/update <3>\n+ -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update\n+$ cat info/allowed-users <4>\n+refs/heads/master\talice\\|cindy\n+refs/heads/doc-update\tbob\n+refs/tags/v[0-9]*\tdavid\n+------------\n++\n+<1> place the developers into the same git group.\n+<2> and make the shared repository writable by the group.\n+<3> use update-hook example by Carl from Documentation/howto/\n+for branch policy control.\n+<4> alice and cindy can push into master, only bob can push into doc-update.\n+david is the release manager and is the only person who can\n+create and push version tags.\n+\n+HTTP server to support dumb protocol transfer.::\n++\n+------------\n+dev$ git update-server-info <1>\n+dev$ ftp user@isp.example.com <2>\n+ftp> cp -r .git /home/user/myproject.git\n+------------\n++\n+<1> make sure your info/refs and objects/info/packs are up-to-date\n+<2> upload to public HTTP server hosted by your ISP.\n-- \n1.8.1.msysgit.1\n"},{"id":"210125","messageId":"1361660761-1932-11-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 10/13] Update Git(1) links to guides","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:58Z","receivedAt":"2013-02-23T23:05:58Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"to giteverday and gituser-manual\n\nSigned-off-by: Philip Oakley \n---\n Documentation/git.txt | 12 ++++++------\n 1 file changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 0b681d9..1830245 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -22,8 +22,8 @@ unusually rich command set that provides both high-level operations\n and full access to internals.\n \n See linkgit:gittutorial[7] to get started, then see\n-link:everyday.html[Everyday Git] for a useful minimum set of\n-commands. The link:user-manual.html[Git User's Manual] has a more\n+linkgit:giteveryday[Everyday Git] for a useful minimum set of\n+commands. The linkgit:gituser-manual[Git User's Manual] has a more\n in-depth introduction.\n \n After you mastered the basic concepts, you can come back to this\n@@ -826,7 +826,7 @@ Discussion[[Discussion]]\n ------------------------\n \n More detail on the following is available from the\n-link:user-manual.html#git-concepts[Git concepts chapter of the\n+linkgit:gituser-manual#git-concepts[git concepts chapter of the\n user-manual] and linkgit:gitcore-tutorial[7].\n \n A Git project normally consists of a working directory with a \".git\"\n@@ -882,7 +882,7 @@ See the references in the \"description\" section to get started\n using Git. The following is probably more detail than necessary\n for a first-time user.\n \n-The link:user-manual.html#git-concepts[Git concepts chapter of the\n+The linkgit:gituser-manual#git-concepts[git concepts chapter of the\n user-manual] and linkgit:gitcore-tutorial[7] both provide\n introductions to the underlying Git architecture.\n \n@@ -919,9 +919,9 @@ subscribed to the list to send a message there.\n SEE ALSO\n --------\n linkgit:gittutorial[7], linkgit:gittutorial-2[7],\n-link:everyday.html[Everyday Git], linkgit:gitcvs-migration[7],\n+linkgit:giteveryday[Everyday Git], linkgit:gitcvs-migration[7],\n linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],\n-linkgit:gitcli[7], link:user-manual.html[The Git User's Manual],\n+linkgit:gitcli[7], linkgit:gituser-manual[The Git User's Manual],\n linkgit:gitworkflows[7]\n \n GIT\n-- \n1.8.1.msysgit.1\n"},{"id":"210127","messageId":"1361660761-1932-12-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 11/13] Add missing guides to list and regenerate","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:05:59Z","receivedAt":"2013-02-23T23:05:59Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Signed-off-by: Philip Oakley \n---\n common-guides.h | 3 +++\n guide-list.txt | 17 +++++++++--------\n 2 files changed, 12 insertions(+), 8 deletions(-)\n\ndiff --git a/common-guides.h b/common-guides.h\nindex a8ad8d1..ae57d75 100644\n--- a/common-guides.h\n+++ b/common-guides.h\n@@ -3,10 +3,13 @@\n \n static struct cmdname_help common_guides[] = {\n {\"attributes\", \"defining attributes per path\"},\n+ {\"everyday\", \"Everyday GIT With 20 Commands Or So\"},\n {\"glossary\", \"A GIT Glossary\"},\n {\"ignore\", \"Specifies intentionally untracked files to ignore\"},\n {\"modules\", \"defining submodule properties\"},\n+ {\"repository-layout\", \"Git Repository Layout\"},\n {\"revisions\", \"specifying revisions and ranges for git\"},\n {\"tutorial\", \"A tutorial introduction to git (for version 1.5.1 or newer)\"},\n+ {\"user-manual\", \"Git User's Manual (for version 1.5.3 or newer)\"},\n {\"workflows\", \"An overview of recommended workflows with git\"},\n };\ndiff --git a/guide-list.txt b/guide-list.txt\nindex a419ac4..9ba1b5b 100644\n--- a/guide-list.txt\n+++ b/guide-list.txt\n@@ -10,7 +10,7 @@ githooks specialist\n gitignore concept\t guide\n gitmodules concept\t guide\n gitnamespaces specialist\n-#gitrepository-layout reference guide\n+gitrepository-layout reference guide\n gitrevisions concept\t guide\n gittutorial user\t guide\n gittutorial-2 user\n@@ -18,12 +18,13 @@ gitweb.conf specialist\n gitweb specialist\n gitworkflows user\t guide\n \n-#giteveryday user\t guide\n-#gituser-manual user\t guide\n+giteveryday user\t guide\n+gituser-manual user\t guide\n \n-# could embed inside common-cmds.h with [guide] as the second thing,\n-# making the sed's in generate-cmdlist.sh more obvious\n-# but drop the dash in 's/^git-\\\n+# Could embed inside common-cmds.h and move generate-guidelist.sh\n+# into generate-cmdlist.sh \n \n-#gitrepository-layout is too long for the current char[16]\n-#\n+# Could also extend generate-guidelist.sh to create a second, complete\n+# list of guides should -gg option be applied twice (It's a countup option)\n+\n+# use './generate-guidelist.sh >common-guides.h' to re-generate.\n-- \n1.8.1.msysgit.1\n"},{"id":"210124","messageId":"1361660761-1932-13-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 12/13] Documentation/Makefile: update git guide links","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:06:00Z","receivedAt":"2013-02-23T23:06:00Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Signed-off-by: Philip Oakley \n---\n Documentation/Makefile | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 62dbd9a..dc759a2 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -23,11 +23,13 @@ MAN7_TXT += gitcore-tutorial.txt\n MAN7_TXT += gitcredentials.txt\n MAN7_TXT += gitcvs-migration.txt\n MAN7_TXT += gitdiffcore.txt\n+MAN7_TXT += giteveryday.txt\n MAN7_TXT += gitglossary.txt\n MAN7_TXT += gitnamespaces.txt\n MAN7_TXT += gitrevisions.txt\n MAN7_TXT += gittutorial-2.txt\n MAN7_TXT += gittutorial.txt\n+MAN7_TXT += gituser-manual.txt\n MAN7_TXT += gitworkflows.txt\n \n MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)\n@@ -35,6 +37,8 @@ MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))\n MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))\n \n OBSOLETE_HTML = git-remote-helpers.html\n+OBSOLETE_HTML = everyday.html\n+OBSOLETE_HTML = user-manual.html\n DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)\n \n ARTICLES = howto-index\n-- \n1.8.1.msysgit.1\n"},{"id":"210123","messageId":"1361660761-1932-14-git-send-email-philipoakley@iee.org","threadId":"32991","inReplyTo":"1361660761-1932-1-git-send-email-philipoakley@iee.org","subject":"[PATCH 13/13] Fixup! doc: giteveryday and user-manual man format","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:06:01Z","receivedAt":"2013-02-23T23:06:01Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Signed-off-by: Philip Oakley \n---\n Documentation/giteveryday.txt | 10 ++++++++--\n Documentation/gituser-manual.txt | 7 ++++++-\n 2 files changed, 14 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt\nindex e1fba85..3f11787 100644\n--- a/Documentation/giteveryday.txt\n+++ b/Documentation/giteveryday.txt\n@@ -1,6 +1,12 @@\n-Everyday Git With 20 Commands Or So\n-===================================\n+Everyday-Git(7)\n+===============\n \n+NAME\n+----\n+giteveryday - A useful minimum set of commands for Everyday Git \n+\n+SYNOPSIS\n+--------\n <> commands are essential for\n anybody who makes a commit, even for somebody who works alone.\n \ndiff --git a/Documentation/gituser-manual.txt b/Documentation/gituser-manual.txt\nindex a4778d7..e991b11 100644\n--- a/Documentation/gituser-manual.txt\n+++ b/Documentation/gituser-manual.txt\n@@ -1,7 +1,12 @@\n Git User's Manual (for version 1.5.3 or newer)\n-______________________________________________\n+==============================================\n \n+NAME\n+----\n+gituser-manual - User Manual for Git, the stupid content tracker\n \n+SYNOPSIS\n+--------\n Git is a fast distributed revision control system.\n \n This manual is designed to be readable by someone with basic UNIX\n-- \n1.8.1.msysgit.1\n"},{"id":"210128","messageId":"CAJDDKr5VG_c_RRK3Z++RNUev=3swmT0HUDocJE1h1QtSHYrYJA@mail.gmail.com","threadId":"32991","inReplyTo":"1361660761-1932-2-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH 01/13] Use 'Git' in help messages","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2013-02-23T23:41:05Z","receivedAt":"2013-02-23T23:41:05Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sat, Feb 23, 2013 at 3:05 PM, Philip Oakley wrote:\n> Signed-off-by: Philip Oakley \n> ---\n> help.c | 12 ++++++------\n> 1 file changed, 6 insertions(+), 6 deletions(-)\n>\n> diff --git a/help.c b/help.c\n> index 1dfa0b0..1c0e17d 100644\n> --- a/help.c\n> +++ b/help.c\n> @@ -209,14 +209,14 @@ void list_commands(unsigned int colopts,\n> {\n> if (main_cmds->cnt) {\n> const char *exec_path = git_exec_path();\n> - printf_ln(_(\"available git commands in '%s'\"), exec_path);\n> + printf_ln(_(\"available Git commands in '%s'\"), exec_path);\n> putchar('\\n');\n> pretty_print_string_list(main_cmds, colopts);\n> putchar('\\n');\n> }\n>\n> if (other_cmds->cnt) {\n> - printf_ln(_(\"git commands available from elsewhere on your $PATH\"));\n> + printf_ln(_(\"Git commands available from elsewhere on your $PATH\"));\n> putchar('\\n');\n> pretty_print_string_list(other_cmds, colopts);\n> putchar('\\n');\n> @@ -232,7 +232,7 @@ void list_common_cmds_help(void)\n> longest = strlen(common_cmds[i].name);\n> }\n>\n> - puts(_(\"The most commonly used git commands are:\"));\n> + puts(_(\"The most commonly used Git commands are:\"));\n> for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {\n> printf(\" %s \", common_cmds[i].name);\n> mput_char(' ', longest - strlen(common_cmds[i].name));\n> @@ -289,7 +289,7 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)\n> #define SIMILAR_ENOUGH(x) ((x) < SIMILARITY_FLOOR)\n>\n> static const char bad_interpreter_advice[] =\n> - N_(\"'%s' appears to be a git command, but we were not\\n\"\n> + N_(\"'%s' appears to be a Git command, but we were not\\n\"\n> \"able to execute it. Maybe git-%s is broken?\");\n>\n> const char *help_unknown_cmd(const char *cmd)\n> @@ -380,7 +380,7 @@ const char *help_unknown_cmd(const char *cmd)\n> return assumed;\n> }\n>\n> - fprintf_ln(stderr, _(\"git: '%s' is not a git command. See 'git --help'.\"), cmd);\n> + fprintf_ln(stderr, _(\"git: '%s' is not a Git command. See 'git --help'.\"), cmd);\n>\n> if (SIMILAR_ENOUGH(best_similarity)) {\n> fprintf_ln(stderr,\n> @@ -397,6 +397,6 @@ const char *help_unknown_cmd(const char *cmd)\n>\n> int cmd_version(int argc, const char **argv, const char *prefix)\n> {\n> - printf(\"git version %s\\n\", git_version_string);\n> + printf(\"Git version %s\\n\", git_version_string);\n> return 0;\n> }\n\nThis is referring to \"git the command\", not \"git the system\",\nso it should not be changed according to the rule that was\napplied when many \"git\" strings were changed to \"Git\".\n\nThere are scripts, etc. in the wild that parse this output.\nwhich is another reason we would not want to change this.\n\nDoes the build system use this output somewhere?\n\nThe other strings in this patch mention \"git commands\" which\nthe user is expected to type, so it might make sense to leave\nthem as-is as well.\n-- \nDavid\n"},{"id":"210129","messageId":"512956A0.2000201@iee.org","threadId":"32991","inReplyTo":"CAJDDKr5VG_c_RRK3Z++RNUev=3swmT0HUDocJE1h1QtSHYrYJA@mail.gmail.com","subject":"Re: [PATCH 01/13] Use 'Git' in help messages","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-23T23:54:08Z","receivedAt":"2013-02-23T23:54:08Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 23/02/13 23:41, David Aguilar wrote:\n> On Sat, Feb 23, 2013 at 3:05 PM, Philip Oakley wrote:\n>> Signed-off-by: Philip Oakley \n>> ---\n>> help.c | 12 ++++++------\n>> 1 file changed, 6 insertions(+), 6 deletions(-)\n>>\n>> diff --git a/help.c b/help.c\n>> index 1dfa0b0..1c0e17d 100644\n>> --- a/help.c\n>> +++ b/help.c\n>> @@ -209,14 +209,14 @@ void list_commands(unsigned int colopts,\n>> {\n>> if (main_cmds->cnt) {\n>> const char *exec_path = git_exec_path();\n>> - printf_ln(_(\"available git commands in '%s'\"), exec_path);\n>> + printf_ln(_(\"available Git commands in '%s'\"), exec_path);\n>> putchar('\\n');\n>> pretty_print_string_list(main_cmds, colopts);\n>> putchar('\\n');\n>> }\n>>\n>> if (other_cmds->cnt) {\n>> - printf_ln(_(\"git commands available from elsewhere on your $PATH\"));\n>> + printf_ln(_(\"Git commands available from elsewhere on your $PATH\"));\n>> putchar('\\n');\n>> pretty_print_string_list(other_cmds, colopts);\n>> putchar('\\n');\n>> @@ -232,7 +232,7 @@ void list_common_cmds_help(void)\n>> longest = strlen(common_cmds[i].name);\n>> }\n>>\n>> - puts(_(\"The most commonly used git commands are:\"));\n>> + puts(_(\"The most commonly used Git commands are:\"));\n>> for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {\n>> printf(\" %s \", common_cmds[i].name);\n>> mput_char(' ', longest - strlen(common_cmds[i].name));\n>> @@ -289,7 +289,7 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)\n>> #define SIMILAR_ENOUGH(x) ((x) < SIMILARITY_FLOOR)\n>>\n>> static const char bad_interpreter_advice[] =\n>> - N_(\"'%s' appears to be a git command, but we were not\\n\"\n>> + N_(\"'%s' appears to be a Git command, but we were not\\n\"\n>> \"able to execute it. Maybe git-%s is broken?\");\n>>\n>> const char *help_unknown_cmd(const char *cmd)\n>> @@ -380,7 +380,7 @@ const char *help_unknown_cmd(const char *cmd)\n>> return assumed;\n>> }\n>>\n>> - fprintf_ln(stderr, _(\"git: '%s' is not a git command. See 'git --help'.\"), cmd);\n>> + fprintf_ln(stderr, _(\"git: '%s' is not a Git command. See 'git --help'.\"), cmd);\n>>\n>> if (SIMILAR_ENOUGH(best_similarity)) {\n>> fprintf_ln(stderr,\n>> @@ -397,6 +397,6 @@ const char *help_unknown_cmd(const char *cmd)\n>>\n>> int cmd_version(int argc, const char **argv, const char *prefix)\n>> {\n>> - printf(\"git version %s\\n\", git_version_string);\n>> + printf(\"Git version %s\\n\", git_version_string);\n>> return 0;\n>> }\n>\n> This is referring to \"git the command\", not \"git the system\",\n> so it should not be changed according to the rule that was\n> applied when many \"git\" strings were changed to \"Git\".\n\nI'd felt that they were referring to 'Git the system', hence the changes.\n>\n> There are scripts, etc. in the wild that parse this output.\n\nMy first pass avoided the 'git --version' response on the basis\nthat it might be used in the tests or elsewhere, but I didn't\nfind an occurrence of it's use (in Git), so I thought 'why not'.\nHowever I'm not wedded to it. If the exact phrase 'git version'\nis parsed in the wild it then we should let it be.\n\n> which is another reason we would not want to change this.\n>\n> Does the build system use this output somewhere?\n>\n> The other strings in this patch mention \"git commands\" which\n> the user is expected to type, so it might make sense to leave\n> them as-is as well.\n>\n"},{"id":"210173","messageId":"7vr4k65box.fsf@alter.siamese.dyndns.org","threadId":"32991","inReplyTo":"CAJDDKr5VG_c_RRK3Z++RNUev=3swmT0HUDocJE1h1QtSHYrYJA@mail.gmail.com","subject":"Re: [PATCH 01/13] Use 'Git' in help messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-24T08:59:58Z","receivedAt":"2013-02-24T08:59:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar writes:\n\n> This is referring to \"git the command\", not \"git the system\",\n> so it should not be changed according to the rule that was\n> applied when many \"git\" strings were changed to \"Git\".\n\nThat sounds like a sensible objection.\n\n> There are scripts, etc. in the wild that parse this output.\n> which is another reason we would not want to change this.\n\nAre there? For what purpose?\n\nEspecially when these are all _(\"l10n ready\"), I find that somewhat\nunlikely.\n\nThe bash completion (in contrib/) does read from the command list\nIIRC. I do not think it relies on the messages, though.\n"},{"id":"210174","messageId":"7vmwuu5bm1.fsf@alter.siamese.dyndns.org","threadId":"32991","inReplyTo":"1361660761-1932-6-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH 05/13] Help.c: add list_common_guides_help() function","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-24T09:01:42Z","receivedAt":"2013-02-24T09:01:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> diff --git a/common-guides.h b/common-guides.h\n> new file mode 100644\n> index 0000000..a8ad8d1\n> --- /dev/null\n> +++ b/common-guides.h\n> @@ -0,0 +1,12 @@\n> +/* Automatically generated by ./generate-guidelist.sh */\n> +/* re-use struct cmdname_help in common-commands.h */\n\nHuh?\n"},{"id":"210181","messageId":"20130224143902.GI1361@odin.tremily.us","threadId":"32991","inReplyTo":"1361660761-1932-3-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH 02/13] Show 'git help ' usage, with examples","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-02-24T14:39:02Z","receivedAt":"2013-02-24T14:39:02Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Feb 23, 2013 at 11:05:50PM +0000, Philip Oakley wrote:\n> +\t \"Examples: 'git help git', 'git help branch', 'git help tutorial'..\");\n\nThis sentence should end in '.', not '..'.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"210182","messageId":"20130224145113.GJ1361@odin.tremily.us","threadId":"32991","inReplyTo":"1361660761-1932-7-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH 06/13] Add guide-list.txt and extraction shell","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-02-24T14:51:13Z","receivedAt":"2013-02-24T14:51:13Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Feb 23, 2013 at 11:05:54PM +0000, Philip Oakley wrote:\n> +# Usage: ./generate-guidelist.sh >>common-guides.h\n\nFollowing David's recent series, it's probably better to use a\nlowercase 'usage' [1]. Also, I'd expect '>common-guides.h' would make\nmore sense than appending with '>>'.\n\n> +/* re-use struct cmdname_help in common-commands.h */\n> +\n> +static struct cmdname_help common_guides[] = {\"\n\nThis is probably just copied from generate-cmdlist.sh, but maybe it\nwould be a good idea to #include \"common-commands.h\" here?\n\nTrevor\n\n[1]: http://article.gmane.org/gmane.comp.version-control.git/216961\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"210183","messageId":"20130224145526.GK1361@odin.tremily.us","threadId":"32991","inReplyTo":"1361660761-1932-10-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH 09/13] Rename everyday to giteveryday","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-02-24T14:55:26Z","receivedAt":"2013-02-24T14:55:26Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Feb 23, 2013 at 11:05:57PM +0000, Philip Oakley wrote:\n> diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt\n> index e1fba85..3fc69f6 100644\n> --- a/Documentation/everyday.txt\n> +++ b/Documentation/everyday.txt\n> @@ -1,413 +1,25 @@\n> -Everyday Git With 20 Commands Or So\n> +Everyday GIT With 20 Commands Or So\n> ===================================\n\nThis looks like it's opposing 48a8c26 (Documentation: avoid poor-man's\nsmall caps GIT, 2013-01-21). Another reason to use 'Git' over 'GIT'\nis to match the page we're redirecting to:\n\n> new file mode 100644\n> index 0000000..e1fba85\n> --- /dev/null\n> +++ b/Documentation/giteveryday.txt\n> @@ -0,0 +1,413 @@\n> +Everyday Git With 20 Commands Or So\n> +===================================\n\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"210184","messageId":"20130224145831.GL1361@odin.tremily.us","threadId":"32991","inReplyTo":"1361660761-1932-13-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH 12/13] Documentation/Makefile: update git guide links","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-02-24T14:58:31Z","receivedAt":"2013-02-24T14:58:31Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Feb 23, 2013 at 11:06:00PM +0000, Philip Oakley wrote:\n> OBSOLETE_HTML = git-remote-helpers.html\n> +OBSOLETE_HTML = everyday.html\n> +OBSOLETE_HTML = user-manual.html\n> DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)\n\nShould be '+=' instead of '='.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"210185","messageId":"20130224150140.GM1361@odin.tremily.us","threadId":"32991","inReplyTo":"1361660761-1932-14-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH 13/13] Fixup! doc: giteveryday and user-manual man format","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-02-24T15:01:40Z","receivedAt":"2013-02-24T15:01:40Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Feb 23, 2013 at 11:06:01PM +0000, Philip Oakley wrote:\n> diff --git a/Documentation/gituser-manual.txt b/Documentation/gituser-manual.txt\n> index a4778d7..e991b11 100644\n> --- a/Documentation/gituser-manual.txt\n> +++ b/Documentation/gituser-manual.txt\n> @@ -1,7 +1,12 @@\n> Git User's Manual (for version 1.5.3 or newer)\n> -______________________________________________\n> +==============================================\n\nI'd be happy dropping the parenthetical bit here. It's hard to\nimagine someone still running something earlier than 1.5.3. It's even\nharder to imagine them installing a modern user manual man page for\ntheir old Git version ;).\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"210195","messageId":"DE540C447A2242E7A162E03B81B4E5CB@PhilipOakley","threadId":"32991","inReplyTo":"7vr4k65box.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 01/13] Use 'Git' in help messages","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-02-24T21:45:26Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Sunday, February 24, 2013 8:59 AM\n> David Aguilar writes:\n>\n>> This is referring to \"git the command\", not \"git the system\",\n>> so it should not be changed according to the rule that was\n>> applied when many \"git\" strings were changed to \"Git\".\n>\n> That sounds like a sensible objection.\n>\n\nI'd read the messages in the tone 'commands of the Git system', but I \ncan see that both views are equally plausible. Though the final _(\"git: \n'%s' is not a Git command. See 'git --help'.\") can't be referring to a \n'git-', obviously ;-)\n\n>> There are scripts, etc. in the wild that parse this output.\n>> which is another reason we would not want to change this.\n>\n> Are there? For what purpose?\n>\n> Especially when these are all _(\"l10n ready\"), I find that somewhat\n> unlikely.\n>\n> The bash completion (in contrib/) does read from the command list\n> IIRC. I do not think it relies on the messages, though.\n\nI was aware of that bash completion used 'git help -a' so I avoided \nchanging the response to that option. Initially I'd thought of making \n'-a' provide both commands and guides but knew I'd need to ensure the \ncompletion would still be sensible. I'd taken Juio's earlier advice to \nkeep '-a' unchanged and simply add the -g|--guides option as a \nsupplemental 'git help' response..\n\nPhilip \n"},{"id":"210196","messageId":"4AEE9909C70D4810A228A367FB888AF4@PhilipOakley","threadId":"32991","inReplyTo":"7vmwuu5bm1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 05/13] Help.c: add list_common_guides_help() function","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-02-24T21:45:26Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Sunday, February 24, 2013 9:01 AM\n> Philip Oakley writes:\n>\n>> diff --git a/common-guides.h b/common-guides.h\n>> new file mode 100644\n>> index 0000000..a8ad8d1\n>> --- /dev/null\n>> +++ b/common-guides.h\n>> @@ -0,0 +1,12 @@\n>> +/* Automatically generated by ./generate-guidelist.sh */\n>> +/* re-use struct cmdname_help in common-commands.h */\n>\n> Huh?\nThe first comment line fortells of patch 6 which can generate this .h \nfile.\nThe second comment line notes that I re-use cmdname_help, rather than \ncreating another struct with a similar name.\n\nI should probably have noted these points in the commit message. (or \nwaited until patch 6 to add the comment).\n\nPhilip \n"},{"id":"210197","messageId":"512A8EBA.4070706@iee.org","threadId":"32991","inReplyTo":"20130224143902.GI1361@odin.tremily.us","subject":"Re: [PATCH 02/13] Show 'git help ' usage, with examples","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-24T22:05:46Z","receivedAt":"2013-02-24T22:05:46Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 24/02/13 14:39, W. Trevor King wrote:\n> On Sat, Feb 23, 2013 at 11:05:50PM +0000, Philip Oakley wrote:\n>> +\t \"Examples: 'git help git', 'git help branch', 'git help tutorial'..\");\n>\n> This sentence should end in '.', not '..'.\n>\n> Cheers,\n> Trevor\n>\nI should have used three as ellipsis ... to suggest 'more', which was my \nintent, but ended up neither here, nor there.\nPhilip\n"},{"id":"210198","messageId":"CAJDDKr4sCBJs_Dq8MdfCJAH4wW7k0TtimW6B01wS6k0zcJ9XHQ@mail.gmail.com","threadId":"32991","inReplyTo":"7vr4k65box.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 01/13] Use 'Git' in help messages","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2013-02-24T22:11:12Z","receivedAt":"2013-02-24T22:11:12Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sun, Feb 24, 2013 at 12:59 AM, Junio C Hamano wrote:\n> David Aguilar writes:\n>\n>> This is referring to \"git the command\", not \"git the system\",\n>> so it should not be changed according to the rule that was\n>> applied when many \"git\" strings were changed to \"Git\".\n>\n> That sounds like a sensible objection.\n>\n>> There are scripts, etc. in the wild that parse this output.\n>> which is another reason we would not want to change this.\n>\n> Are there? For what purpose?\n>\n> Especially when these are all _(\"l10n ready\"), I find that somewhat\n> unlikely.\n\nA script might conditionally use new git behavior and parse the\noutput of \"git version\" to determine whether or not it can use it.\noh-my-zsh does this, for example [*].\n\nChanging the git to Git is probably fine for some scripts that\ndo something interesting based on the git version since they\nmight be doing something simple like splitting the string on\nwhitespace and taking the last element as the version number.\n\nThese won't be broken by this change, but this approach is\nalready broken for a different reason. Apple's build of git\nprints \"git version 1.7.12.4 (Apple Git-37)\" so they would\nneed to account for the last parens section optionally\nbeing there. Changing \"git\" to \"Git\" only breaks anyone that\nhas assumed that they could get the version by doing\ns/git version// on the string.\n\nI think being able to find the version at runtime is something\nthat is typically used by packagers and folks that want to be\nportable across git versions. For these, it would be helpful\nto have a consistent and stable output that can be easily parsed.\n\nBy deciding to not mark these l10n ready and keeping the output\nconsistent we could help that use case.\n\n[*] I'm not saying this is a good idea or something that scripts\nshould do, I'm just pointing out that it is done in practice,\nso it is worth considering their use cases.\n-- \nDavid\n"},{"id":"210200","messageId":"512A9066.3040204@iee.org","threadId":"32991","inReplyTo":"20130224145113.GJ1361@odin.tremily.us","subject":"Re: [PATCH 06/13] Add guide-list.txt and extraction shell","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-24T22:12:54Z","receivedAt":"2013-02-24T22:12:54Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 24/02/13 14:51, W. Trevor King wrote:\n> On Sat, Feb 23, 2013 at 11:05:54PM +0000, Philip Oakley wrote:\n>> +# Usage: ./generate-guidelist.sh >>common-guides.h\n>\n> Following David's recent series, it's probably better to use a\n> lowercase 'usage' [1].\nI prefer the Initial capital version to suggest the start of a sentence, \nbut I can go with either way.\n\n> Also, I'd expect '>common-guides.h' would make\n> more sense than appending with '>>'.\n\nMy mistake. Will correct.\n\n>\n>> +/* re-use struct cmdname_help in common-commands.h */\n>> +\n>> +static struct cmdname_help common_guides[] = {\"\n>\n> This is probably just copied from generate-cmdlist.sh, but maybe it\n> would be a good idea to #include \"common-commands.h\" here?\n\nI was trying to avoid nested includes. Eventually, if the series is \naccepted, I'd want to refactor the guide generation into the existing \ncommand generation so that .h file would then disappear.\n>\n> Trevor\n>\n> [1]: http://article.gmane.org/gmane.comp.version-control.git/216961\n>\nPhilip\n"},{"id":"210201","messageId":"512A912B.8080807@iee.org","threadId":"32991","inReplyTo":"20130224145526.GK1361@odin.tremily.us","subject":"Re: [PATCH 09/13] Rename everyday to giteveryday","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-24T22:16:11Z","receivedAt":"2013-02-24T22:16:11Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 24/02/13 14:55, W. Trevor King wrote:\n> On Sat, Feb 23, 2013 at 11:05:57PM +0000, Philip Oakley wrote:\n>> diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt\n>> index e1fba85..3fc69f6 100644\n>> --- a/Documentation/everyday.txt\n>> +++ b/Documentation/everyday.txt\n>> @@ -1,413 +1,25 @@\n>> -Everyday Git With 20 Commands Or So\n>> +Everyday GIT With 20 Commands Or So\n>> ===================================\n>\n> This looks like it's opposing 48a8c26 (Documentation: avoid poor-man's\n> small caps GIT, 2013-01-21). Another reason to use 'Git' over 'GIT'\n> is to match the page we're redirecting to:\n\nMy mistake. When I was separating out the changes into separate patches \nI incorrectly restored/copied an old version of the title.\n\nWill correct.\n\n>\n>> new file mode 100644\n>> index 0000000..e1fba85\n>> --- /dev/null\n>> +++ b/Documentation/giteveryday.txt\n>> @@ -0,0 +1,413 @@\n>> +Everyday Git With 20 Commands Or So\n>> +===================================\n>\n> Trevor\n>\nPhilip\n"},{"id":"210202","messageId":"512A94D1.3050900@iee.org","threadId":"32991","inReplyTo":"20130224145831.GL1361@odin.tremily.us","subject":"Re: [PATCH 12/13] Documentation/Makefile: update git guide links","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-24T22:31:45Z","receivedAt":"2013-02-24T22:31:45Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 24/02/13 14:58, W. Trevor King wrote:\n> On Sat, Feb 23, 2013 at 11:06:00PM +0000, Philip Oakley wrote:\n>> OBSOLETE_HTML = git-remote-helpers.html\n>> +OBSOLETE_HTML = everyday.html\n>> +OBSOLETE_HTML = user-manual.html\n>> DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)\n>\n> Should be '+=' instead of '='.\n>\nWell spotted. That maybe part of why my make of the documentation failed.\n\nThough the 'new' giteveryday gituser-manual don't build as man pages, so \nI may simply leave them with their old make process - If I understand \ncorrectly they are in the right place and just need the 'git' prefix.\n\nHowever I'm biased by my Msysgit/G4W experience which always assumes \n--web and fires up the HTML version so there may be issues with the \nplain .txt version attempting to be displayed as a man page if it \ndoesn't follow the format. (my linux laptop was a repair of a 'scrapper')\n\nPhilip\n"},{"id":"210203","messageId":"512A94F3.9030607@iee.org","threadId":"32991","inReplyTo":"20130224150140.GM1361@odin.tremily.us","subject":"Re: [PATCH 13/13] Fixup! doc: giteveryday and user-manual man format","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-24T22:32:19Z","receivedAt":"2013-02-24T22:32:19Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 24/02/13 15:01, W. Trevor King wrote:\n> On Sat, Feb 23, 2013 at 11:06:01PM +0000, Philip Oakley wrote:\n>> diff --git a/Documentation/gituser-manual.txt b/Documentation/gituser-manual.txt\n>> index a4778d7..e991b11 100644\n>> --- a/Documentation/gituser-manual.txt\n>> +++ b/Documentation/gituser-manual.txt\n>> @@ -1,7 +1,12 @@\n>> Git User's Manual (for version 1.5.3 or newer)\n>> -______________________________________________\n>> +==============================================\n>\n> I'd be happy dropping the parenthetical bit here. It's hard to\n> imagine someone still running something earlier than 1.5.3. It's even\n> harder to imagine them installing a modern user manual man page for\n> their old Git version ;).\n>\nSensible. Will do.\n\nPhilip\n"},{"id":"210216","messageId":"7vk3px3qzp.fsf@alter.siamese.dyndns.org","threadId":"32991","inReplyTo":"4AEE9909C70D4810A228A367FB888AF4@PhilipOakley","subject":"Re: [PATCH 05/13] Help.c: add list_common_guides_help() function","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-25T05:24:42Z","receivedAt":"2013-02-25T05:24:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> From: \"Junio C Hamano\" \n> Sent: Sunday, February 24, 2013 9:01 AM\n>> Philip Oakley writes:\n>>\n>>> diff --git a/common-guides.h b/common-guides.h\n>>> new file mode 100644\n>>> index 0000000..a8ad8d1\n>>> --- /dev/null\n>>> +++ b/common-guides.h\n>>> @@ -0,0 +1,12 @@\n>>> +/* Automatically generated by ./generate-guidelist.sh */\n>>> +/* re-use struct cmdname_help in common-commands.h */\n>>\n>> Huh?\n> The first comment line fortells of patch 6 which can generate this .h\n> file.\n\nThe Huh? was about that one, not about reuse. I do not want to see\na build artifact kept in the history without a good reason.\n"},{"id":"210217","messageId":"7vd2vp3qru.fsf@alter.siamese.dyndns.org","threadId":"32991","inReplyTo":"1361660761-1932-13-git-send-email-philipoakley@iee.org","subject":"Re: [PATCH 12/13] Documentation/Makefile: update git guide links","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-25T05:29:25Z","receivedAt":"2013-02-25T05:29:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> @@ -35,6 +37,8 @@ MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))\n> MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))\n> \n> OBSOLETE_HTML = git-remote-helpers.html\n> +OBSOLETE_HTML = everyday.html\n> +OBSOLETE_HTML = user-manual.html\n> DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)\n\nIf you are keeping track of inventory of \"guides\" in a new static\narray, do you still need to look up \"giteveryday\" or \"gituser-manual\"\nwhen the user asks for guide documents?\n\nIn other words, can't you change the side that launches the document\nviewer so that we do not have to rename anything in the first place?\n"},{"id":"210307","messageId":"512BF71E.3080304@iee.org","threadId":"32991","inReplyTo":"7vd2vp3qru.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 12/13] Documentation/Makefile: update git guide links","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-25T23:43:26Z","receivedAt":"2013-02-25T23:43:26Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 25/02/13 05:29, Junio C Hamano wrote:\n> Philip Oakley writes:\n>\n>> @@ -35,6 +37,8 @@ MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))\n>> MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))\n>>\n>> OBSOLETE_HTML = git-remote-helpers.html\n>> +OBSOLETE_HTML = everyday.html\n>> +OBSOLETE_HTML = user-manual.html\n>> DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)\n>\n> If you are keeping track of inventory of \"guides\" in a new static\n> array, do you still need to look up \"giteveryday\" or \"gituser-manual\"\n> when the user asks for guide documents?\n\nI'm only keeping track in the new static array of the 'common guides' \nand I'd hoped that these two could be included.\n>\n> In other words, can't you change the side that launches the document\n> viewer so that we do not have to rename anything in the first place?\n>\n\nThe current help code will only show either 'git-' man pages, or \n'git' pages so the current everyday and user-manual pages aren't \nserved by the existing help code.\n\t$ git help everyday\n\tNo manual entry for giteveryday\nHence the need for the rename and 'obsolete page' entries.\n\nI'm guessing that serving any old .txt or .html page from the \nDocumentation directories isn't sensible (rather than being prefix \nbased), but it is a possibility.\n\nPhilip\n"},{"id":"210308","messageId":"512BF72F.9030404@iee.org","threadId":"32991","inReplyTo":"7vk3px3qzp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 05/13] Help.c: add list_common_guides_help() function","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-25T23:43:43Z","receivedAt":"2013-02-25T23:43:43Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 25/02/13 05:24, Junio C Hamano wrote:\n> \"Philip Oakley\" writes:\n>\n>> From: \"Junio C Hamano\" \n>> Sent: Sunday, February 24, 2013 9:01 AM\n>>> Philip Oakley writes:\n>>>\n>>>> diff --git a/common-guides.h b/common-guides.h\n>>>> new file mode 100644\n>>>> index 0000000..a8ad8d1\n>>>> --- /dev/null\n>>>> +++ b/common-guides.h\n>>>> @@ -0,0 +1,12 @@\n>>>> +/* Automatically generated by ./generate-guidelist.sh */\n>>>> +/* re-use struct cmdname_help in common-commands.h */\n>>>\n>>> Huh?\n>> The first comment line fortells of patch 6 which can generate this .h\n>> file.\n>\n> The Huh? was about that one, not about reuse. I do not want to see\n> a build artifact kept in the history without a good reason.\n>\nI'd copied it from generate-cmdlist.sh which is a common-cmd.h \ndependency and was introduced by\n\ncommit a87cd02ce02e97083eb76eb8b9bfeb2e46800fd7\nAuthor: Fredrik Kuivinen \nDate: Thu Mar 9 17:24:19 2006 +0100\n\n Nicer output from 'git'\n\n [jc: with suggestions by Jan-Benedict Glaw]\n\n Signed-off-by: Fredrik Kuivinen \n Signed-off-by: Junio C Hamano \n\nThe reason in this (my) case, as then, is that it states how the file is \ngenerated so that it can be regenerated later. If the patches are \nsuccessful then I'd want the generate-guidelist and generate-cmdlist to \nbe joined together as an integral part of generating the help system data.\n\nMind you each review point turns over another stone that needs to be \nconsidered, such as the Makefile link of common-commands.h and similarly \nfor the Documentation/Makefile - I'm thinking of the issues around \n'gitk' and its ilk which isn't a common command (because it has no \nhyphen) yet is in the command list, so can be confused with the support \ndocumentation, however I don't mark it as a common guide, so that's OK. \n('git help k' does offer the gitk man page ;-)\n\nI'll tidy up the series over the next few days to include the points so far\n\nPhilip\n"},{"id":"210310","messageId":"7vehg4ne2g.fsf@alter.siamese.dyndns.org","threadId":"32991","inReplyTo":"512BF72F.9030404@iee.org","subject":"Re: [PATCH 05/13] Help.c: add list_common_guides_help() function","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-25T23:55:51Z","receivedAt":"2013-02-25T23:55:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n>>> The first comment line fortells of patch 6 which can generate this .h\n>>> file.\n>>\n>> The Huh? was about that one, not about reuse. I do not want to see\n>> a build artifact kept in the history without a good reason.\n>>\n> I'd copied it from generate-cmdlist.sh which is a common-cmd.h\n> dependency and was introduced by\n>\n> commit a87cd02ce02e97083eb76eb8b9bfeb2e46800fd7\n> Author: Fredrik Kuivinen \n> Date: Thu Mar 9 17:24:19 2006 +0100\n>\n> Nicer output from 'git'\n>\n> [jc: with suggestions by Jan-Benedict Glaw]\n>\n> Signed-off-by: Fredrik Kuivinen \n> Signed-off-by: Junio C Hamano \n\nLooking at the change again, I do not see us adding a build artifact\n(in the case of that patch, common-cmd.h) to our history. Only the\nrecipe to generate that file exists there, which is the right thing\nto do.\n\nWhy do we want common-guides.h which is clearly marked as \"A\ngenerated file\" at its top in our history? That was what made me\nsay \"Huh?\".\n"},{"id":"210311","messageId":"7va9qsndnn.fsf@alter.siamese.dyndns.org","threadId":"32991","inReplyTo":"512BF71E.3080304@iee.org","subject":"Re: [PATCH 12/13] Documentation/Makefile: update git guide links","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-26T00:04:44Z","receivedAt":"2013-02-26T00:04:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> On 25/02/13 05:29, Junio C Hamano wrote:\n> ...\n>> In other words, can't you change the side that launches the document\n>> viewer so that we do not have to rename anything in the first place?\n>\n> The current help code will only show either 'git-' man pages, or\n> git' pages so the current everyday and user-manual pages aren't\n> served by the existing help code.\n\nThat is exactly what I meant by \"the side that launches the document\nviewer\". We obviously would not want to type\n\n\t$ git help gituser-manual\n $ git help giteveryday\n\nI was wondering if you can keep document names as-is, register these\nnames without \"git\" prefix (i.e. \"user-manual.html\") to the list of\nguide documents you are generating and compiling into the binary,\nand let the user ask:\n\n\t$ git help everyday\n\nwhich you would turn into \"browser %s/%s.html\" % (GIT_HTML_PATH, 'everyday'),\nafter checking \"everyday\" is one of the guides that are available to us.\n\nIf some guides are already named with git prefix, you can keep them\nin the compiled-in list with that name. We do not have to worry\nabout redirects and people's bookmarks if we can avoid renaming\nexisting pages, so \"because grabbing everything with git* glob was\neasier to write the generate-guidelist script\" is a false economy.\nThat is the single place we can afford to spend extra effort to make\nthe end result easier to use by the users, no?\n\nOr am I misreading the series completely?\n"},{"id":"210365","messageId":"512D1A0D.7020203@iee.org","threadId":"32991","inReplyTo":"7va9qsndnn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 12/13] Documentation/Makefile: update git guide links","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-02-26T20:24:45Z","receivedAt":"2013-02-26T20:24:45Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 26/02/13 00:04, Junio C Hamano wrote:\n> Philip Oakley writes:\n>\n>> On 25/02/13 05:29, Junio C Hamano wrote:\n>> ...\n>>> In other words, can't you change the side that launches the document\n>>> viewer so that we do not have to rename anything in the first place?\n>>\n>> The current help code will only show either 'git-' man pages, or\n>> git' pages so the current everyday and user-manual pages aren't\n>> served by the existing help code.\n>\n> That is exactly what I meant by \"the side that launches the document\n> viewer\". We obviously would not want to type\n>\n> \t$ git help gituser-manual\n> $ git help giteveryday\nNeither do I...\n\n>\n> I was wondering if you can keep document names as-is, register these\n> names without \"git\" prefix (i.e. \"user-manual.html\")\n\nI don't register them at all. I'm simply gathering a list of common \nguides in the array so that I can show that list as a 'usage' list, in \nexactly the same manner as the common commands list is used when 'git \nhelp' [ no options] is typed.\n\n> to the list of\n> guide documents you are generating and compiling into the binary,\n> and let the user ask:\n>\n> \t$ git help everyday\n\nThis is the existing way.\n'git help tutorial' will display the gittutorial.txt man page - Note the \ngit prefix is required by the code.\n\nIt is interesting to note that 'git help k' and 'git help gitk' produce \nthe same response, while gitk can't be a common-command because it \ndoesn't have a dashed form so isn't picked up by the script ;-)\n\n>\n> which you would turn into \"browser %s/%s.html\" % (GIT_HTML_PATH, 'everyday'),\n> after checking \"everyday\" is one of the guides that are available to us.\n>\n> If some guides are already named with git prefix, you can keep them\n> in the compiled-in list with that name. We do not have to worry\n> about redirects and people's bookmarks if we can avoid renaming\n> existing pages, so \"because grabbing everything with git* glob was\n> easier to write the generate-guidelist script\" is a false economy.\n\nI was hoping to avoid more special casing of special files for special \npurposes..\n> That is the single place we can afford to spend extra effort to make\n> the end result easier to use by the users, no?\nIt could be done.\n\n>\n> Or am I misreading the series completely?\nYes, I think so (in terms of my starting point and approach).\n\nI was using the existing common-commands approach _just_ to display a \n'usage' string of common guides. so that new users would be informed of \ntheir presence, and then they would use the existing command 'git help \n' to read about it (see also patch 2/13).\n\nIt was just unfortunate that the user-manual and everyday didn't fit the \nexisting naming pattern causing the writing of patch 8 & 9 et seq to \nsort the renames to fit the pattern (just like git-remote-helpers)\n\nAlso, I think it's the user-manual, one of the files doesn't fit the \n'man page' style required by the MAN7 list in Documentation/Makefile, so \nthat's another potential complication I need to bottom out - most likely \nkeep it 'as is' in the Makefile and check that the Help command will \ndisplay it properly if done that way.\n\nPhilip\n"}]}