* [PATCH 02/13] Show 'git help <guide>' usage, with examples
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
The git(1) man page must be accessed via 'git help git' on Git for Windows
as it has no 'man' command. And it prompts users to read the git(1) page,
rather than hoping they follow a subsidiary link within another documentation
page. The 'tutorial' is an obvious guide to suggest.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
git.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git.c b/git.c
index b10c18b..bf0e0de 100644
--- a/git.c
+++ b/git.c
@@ -13,7 +13,9 @@ const char git_usage_string[] =
" <command> [<args>]";
const char git_more_info_string[] =
- N_("See 'git help <command>' for more information on a specific command.");
+ N_("See 'git help <command>' for more information on a specific command.\n"
+ "While 'git help <guide>', will show the selected Git concept guide.\n"
+ "Examples: 'git help git', 'git help branch', 'git help tutorial'..");
static struct startup_info git_startup_info;
static int use_pager = -1;
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 07/13] Extend name string for longer names
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
generate-cmdlist.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 9a4c9b9..c25561f 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -2,7 +2,7 @@
echo "/* Automatically generated by $0 */
struct cmdname_help {
- char name[16];
+ char name[20];
char help[80];
};
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 05/13] Help.c: add list_common_guides_help() function
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
Re-use list_common_cmds_help but simply change the array name.
Candidate for future refactoring to pass a pointer to the array.
Do not list User-manual and Everday Git which not follow the naming
convention, nor gitrepository-layout which doesn't fit within the name field size
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
builtin/help.c | 1 +
common-guides.h | 12 ++++++++++++
help.c | 18 ++++++++++++++++++
help.h | 1 +
4 files changed, 32 insertions(+)
create mode 100644 common-guides.h
diff --git a/builtin/help.c b/builtin/help.c
index 699e679..b0746af 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -434,6 +434,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (!show_guides) return 0;
}
if (show_guides) {
+ list_common_guides_help();
return 0;
}
if (!argv[0]) {
diff --git a/common-guides.h b/common-guides.h
new file mode 100644
index 0000000..a8ad8d1
--- /dev/null
+++ b/common-guides.h
@@ -0,0 +1,12 @@
+/* Automatically generated by ./generate-guidelist.sh */
+/* re-use struct cmdname_help in common-commands.h */
+
+static struct cmdname_help common_guides[] = {
+ {"attributes", "defining attributes per path"},
+ {"glossary", "A GIT Glossary"},
+ {"ignore", "Specifies intentionally untracked files to ignore"},
+ {"modules", "defining submodule properties"},
+ {"revisions", "specifying revisions and ranges for git"},
+ {"tutorial", "A tutorial introduction to git (for version 1.5.1 or newer)"},
+ {"workflows", "An overview of recommended workflows with git"},
+};
diff --git a/help.c b/help.c
index 1c0e17d..94df446 100644
--- a/help.c
+++ b/help.c
@@ -4,6 +4,7 @@
#include "levenshtein.h"
#include "help.h"
#include "common-cmds.h"
+#include "common-guides.h"
#include "string-list.h"
#include "column.h"
#include "version.h"
@@ -240,6 +241,23 @@ void list_common_cmds_help(void)
}
}
+void list_common_guides_help(void)
+{
+ int i, longest = 0;
+
+ for (i = 0; i < ARRAY_SIZE(common_guides); i++) {
+ if (longest < strlen(common_guides[i].name))
+ longest = strlen(common_guides[i].name);
+ }
+
+ puts(_("The common Git guides are:"));
+ for (i = 0; i < ARRAY_SIZE(common_guides); i++) {
+ printf(" %s ", common_guides[i].name);
+ mput_char(' ', longest - strlen(common_guides[i].name));
+ puts(_(common_guides[i].help));
+ }
+}
+
int is_in_cmdlist(struct cmdnames *c, const char *s)
{
int i;
diff --git a/help.h b/help.h
index 0ae5a12..4ae1fd7 100644
--- a/help.h
+++ b/help.h
@@ -17,6 +17,7 @@ static inline void mput_char(char c, unsigned int num)
}
extern void list_common_cmds_help(void);
+extern void list_common_guides_help(void);
extern const char *help_unknown_cmd(const char *cmd);
extern void load_command_list(const char *prefix,
struct cmdnames *main_cmds,
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 06/13] Add guide-list.txt and extraction shell
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
The guide-list.txt uses exactly the same format as command-list.txt
so could be merged as part of a refactoring.
The category naming for each guide is an initial suggestion and
is not yet used. Only those with the 'guide' prefix are copied
by the generate-guidelist.sh into the common-guides.h file.
The user-manual.txt and everyday.txt do not have the correct filename
format yet. And gitrepository-layout.txt name is too long to include.
So comment them out.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
The shell script function N_() does not appear to work correctly on my
Ubuntu lash-up, so an simpler script line is used with the original
commented out.
---
generate-guidelist.sh | 23 +++++++++++++++++++++++
guide-list.txt | 29 +++++++++++++++++++++++++++++
2 files changed, 52 insertions(+)
create mode 100644 generate-guidelist.sh
create mode 100644 guide-list.txt
diff --git a/generate-guidelist.sh b/generate-guidelist.sh
new file mode 100644
index 0000000..c0c98eb
--- /dev/null
+++ b/generate-guidelist.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+# Usage: ./generate-guidelist.sh >>common-guides.h
+# based on generate-cmdlist.sh
+echo "/* Automatically generated by $0 */
+/* re-use struct cmdname_help in common-commands.h */
+
+static struct cmdname_help common_guides[] = {"
+
+sed -n -e 's/^git\([^ ]*\)[ ].* guide.*/\1/p' guide-list.txt |
+sort |
+while read guide
+do
+ sed -n '
+ /^NAME/,/git'"$guide"'/H
+ ${
+ x
+# s/.*git'"$guide"' - \(.*\)/ {"'"$guide"'", N_("\1")},/
+ s/.*git'"$guide"' - \(.*\)/ {"'"$guide"'", "\1"},/
+ p
+ }' "Documentation/git$guide.txt"
+done
+echo "};"
+
diff --git a/guide-list.txt b/guide-list.txt
new file mode 100644
index 0000000..a419ac4
--- /dev/null
+++ b/guide-list.txt
@@ -0,0 +1,29 @@
+# List of known git guides.
+# guide name category [deprecated] [common] [guide]
+gitattributes concept guide
+gitcore-tutorial specialist
+gitcredentials specialist
+gitcvs-migration specialist
+gitdiffcore specialist
+gitglossary reference guide
+githooks specialist
+gitignore concept guide
+gitmodules concept guide
+gitnamespaces specialist
+#gitrepository-layout reference guide
+gitrevisions concept guide
+gittutorial user guide
+gittutorial-2 user
+gitweb.conf specialist
+gitweb specialist
+gitworkflows user guide
+
+#giteveryday user guide
+#gituser-manual user guide
+
+# could embed inside common-cmds.h with [guide] as the second thing,
+# making the sed's in generate-cmdlist.sh more obvious
+# but drop the dash in 's/^git-\
+
+#gitrepository-layout is too long for the current char[16]
+#
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 04/13] Help.c add --guide option
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
Logic, but no actions, included.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
builtin/help.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index d10cbed..699e679 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -36,10 +36,12 @@ enum help_format {
static const char *html_path;
static int show_all = 0;
+static int show_guides = 0;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
OPT_COUNTUP('a', "all", &show_all, N_("print all available commands")),
+ OPT_COUNTUP('g', "guides", &show_guides, N_("print all available guides")),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
@@ -49,7 +51,7 @@ static struct option builtin_help_options[] = {
};
static const char * const builtin_help_usage[] = {
- N_("git help [--all] [--man|--web|--info] [command]"),
+ N_("git help [--all] [--guides] [--man|--web|--info] [command]"),
NULL
};
@@ -429,9 +431,11 @@ int cmd_help(int argc, const char **argv, const char *prefix)
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));
+ if (!show_guides) return 0;
+ }
+ if (show_guides) {
return 0;
}
-
if (!argv[0]) {
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_common_cmds_help();
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 03/13] Help.c use OPT_COUNTUP
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
rename deprecated option in preparation for 'git help --guides'.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
builtin/help.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/help.c b/builtin/help.c
index d1d7181..d10cbed 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -39,7 +39,7 @@ static int show_all = 0;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
- OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+ OPT_COUNTUP('a', "all", &show_all, N_("print all available commands")),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 12/13] Documentation/Makefile: update git guide links
From: Philip Oakley @ 2013-02-23 23:06 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 62dbd9a..dc759a2 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -23,11 +23,13 @@ MAN7_TXT += gitcore-tutorial.txt
MAN7_TXT += gitcredentials.txt
MAN7_TXT += gitcvs-migration.txt
MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += giteveryday.txt
MAN7_TXT += gitglossary.txt
MAN7_TXT += gitnamespaces.txt
MAN7_TXT += gitrevisions.txt
MAN7_TXT += gittutorial-2.txt
MAN7_TXT += gittutorial.txt
+MAN7_TXT += gituser-manual.txt
MAN7_TXT += gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
@@ -35,6 +37,8 @@ MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
OBSOLETE_HTML = git-remote-helpers.html
+OBSOLETE_HTML = everyday.html
+OBSOLETE_HTML = user-manual.html
DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)
ARTICLES = howto-index
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 10/13] Update Git(1) links to guides
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
to giteverday and gituser-manual
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/git.txt | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 0b681d9..1830245 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -22,8 +22,8 @@ unusually rich command set that provides both high-level operations
and full access to internals.
See linkgit:gittutorial[7] to get started, then see
-link:everyday.html[Everyday Git] for a useful minimum set of
-commands. The link:user-manual.html[Git User's Manual] has a more
+linkgit:giteveryday[Everyday Git] for a useful minimum set of
+commands. The linkgit:gituser-manual[Git User's Manual] has a more
in-depth introduction.
After you mastered the basic concepts, you can come back to this
@@ -826,7 +826,7 @@ Discussion[[Discussion]]
------------------------
More detail on the following is available from the
-link:user-manual.html#git-concepts[Git concepts chapter of the
+linkgit:gituser-manual#git-concepts[git concepts chapter of the
user-manual] and linkgit:gitcore-tutorial[7].
A Git project normally consists of a working directory with a ".git"
@@ -882,7 +882,7 @@ See the references in the "description" section to get started
using Git. The following is probably more detail than necessary
for a first-time user.
-The link:user-manual.html#git-concepts[Git concepts chapter of the
+The linkgit:gituser-manual#git-concepts[git concepts chapter of the
user-manual] and linkgit:gitcore-tutorial[7] both provide
introductions to the underlying Git architecture.
@@ -919,9 +919,9 @@ subscribed to the list to send a message there.
SEE ALSO
--------
linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-link:everyday.html[Everyday Git], linkgit:gitcvs-migration[7],
+linkgit:giteveryday[Everyday Git], linkgit:gitcvs-migration[7],
linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
-linkgit:gitcli[7], link:user-manual.html[The Git User's Manual],
+linkgit:gitcli[7], linkgit:gituser-manual[The Git User's Manual],
linkgit:gitworkflows[7]
GIT
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 13/13] Fixup! doc: giteveryday and user-manual man format
From: Philip Oakley @ 2013-02-23 23:06 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/giteveryday.txt | 10 ++++++++--
Documentation/gituser-manual.txt | 7 ++++++-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt
index e1fba85..3f11787 100644
--- a/Documentation/giteveryday.txt
+++ b/Documentation/giteveryday.txt
@@ -1,6 +1,12 @@
-Everyday Git With 20 Commands Or So
-===================================
+Everyday-Git(7)
+===============
+NAME
+----
+giteveryday - A useful minimum set of commands for Everyday Git
+
+SYNOPSIS
+--------
<<Individual Developer (Standalone)>> commands are essential for
anybody who makes a commit, even for somebody who works alone.
diff --git a/Documentation/gituser-manual.txt b/Documentation/gituser-manual.txt
index a4778d7..e991b11 100644
--- a/Documentation/gituser-manual.txt
+++ b/Documentation/gituser-manual.txt
@@ -1,7 +1,12 @@
Git User's Manual (for version 1.5.3 or newer)
-______________________________________________
+==============================================
+NAME
+----
+gituser-manual - User Manual for Git, the stupid content tracker
+SYNOPSIS
+--------
Git is a fast distributed revision control system.
This manual is designed to be readable by someone with basic UNIX
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 09/13] Rename everyday to giteveryday
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
and leave a 'page has moved' page.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/everyday.txt | 424 ++----------------------------------------
Documentation/giteveryday.txt | 413 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 431 insertions(+), 406 deletions(-)
create mode 100644 Documentation/giteveryday.txt
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index e1fba85..3fc69f6 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -1,413 +1,25 @@
-Everyday Git With 20 Commands Or So
+Everyday GIT With 20 Commands Or So
===================================
-<<Individual Developer (Standalone)>> commands are essential for
-anybody who makes a commit, even for somebody who works alone.
+NAME
+----
+everyday - obsoleted page
-If you work with other people, you will need commands listed in
-the <<Individual Developer (Participant)>> section as well.
+SYNOPSIS
+--------
+See linkgit:giteveryday.
-People who play the <<Integrator>> role need to learn some more
-commands in addition to the above.
+DESCRIPTION
+-----------
+This document has been moved to linkgit:giteveryday.
-<<Repository Administration>> commands are for system
-administrators who are responsible for the care and feeding
-of Git repositories.
+Please let the owners of the referring site know so that they can update the
+link you clicked to get here.
+SEE ALSO
+--------
+linkgit:giteveryday
-Individual Developer (Standalone)[[Individual Developer (Standalone)]]
-----------------------------------------------------------------------
-
-A standalone individual developer does not exchange patches with
-other people, and works alone in a single repository, using the
-following commands.
-
- * linkgit:git-init[1] to create a new repository.
-
- * linkgit:git-show-branch[1] to see where you are.
-
- * linkgit:git-log[1] to see what happened.
-
- * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
- branches.
-
- * linkgit:git-add[1] to manage the index file.
-
- * linkgit:git-diff[1] and linkgit:git-status[1] to see what
- you are in the middle of doing.
-
- * linkgit:git-commit[1] to advance the current branch.
-
- * linkgit:git-reset[1] and linkgit:git-checkout[1] (with
- pathname parameters) to undo changes.
-
- * linkgit:git-merge[1] to merge between local branches.
-
- * linkgit:git-rebase[1] to maintain topic branches.
-
- * linkgit:git-tag[1] to mark known point.
-
-Examples
-~~~~~~~~
-
-Use a tarball as a starting point for a new repository.::
-+
-------------
-$ tar zxf frotz.tar.gz
-$ cd frotz
-$ git init
-$ git add . <1>
-$ git commit -m "import of frotz source tree."
-$ git tag v2.43 <2>
-------------
-+
-<1> add everything under the current directory.
-<2> make a lightweight, unannotated tag.
-
-Create a topic branch and develop.::
-+
-------------
-$ git checkout -b alsa-audio <1>
-$ edit/compile/test
-$ git checkout -- curses/ux_audio_oss.c <2>
-$ git add curses/ux_audio_alsa.c <3>
-$ edit/compile/test
-$ git diff HEAD <4>
-$ git commit -a -s <5>
-$ edit/compile/test
-$ git reset --soft HEAD^ <6>
-$ edit/compile/test
-$ git diff ORIG_HEAD <7>
-$ git commit -a -c ORIG_HEAD <8>
-$ git checkout master <9>
-$ git merge alsa-audio <10>
-$ git log --since='3 days ago' <11>
-$ git log v2.43.. curses/ <12>
-------------
-+
-<1> create a new topic branch.
-<2> revert your botched changes in `curses/ux_audio_oss.c`.
-<3> you need to tell Git if you added a new file; removal and
-modification will be caught if you do `git commit -a` later.
-<4> to see what changes you are committing.
-<5> commit everything as you have tested, with your sign-off.
-<6> take the last commit back, keeping what is in the working tree.
-<7> look at the changes since the premature commit we took back.
-<8> redo the commit undone in the previous step, using the message
-you originally wrote.
-<9> switch to the master branch.
-<10> merge a topic branch into your master branch.
-<11> review commit logs; other forms to limit output can be
-combined and include `--max-count=10` (show 10 commits),
-`--until=2005-12-10`, etc.
-<12> view only the changes that touch what's in `curses/`
-directory, since `v2.43` tag.
-
-
-Individual Developer (Participant)[[Individual Developer (Participant)]]
-------------------------------------------------------------------------
-
-A developer working as a participant in a group project needs to
-learn how to communicate with others, and uses these commands in
-addition to the ones needed by a standalone developer.
-
- * linkgit:git-clone[1] from the upstream to prime your local
- repository.
-
- * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin"
- to keep up-to-date with the upstream.
-
- * linkgit:git-push[1] to shared repository, if you adopt CVS
- style shared repository workflow.
-
- * linkgit:git-format-patch[1] to prepare e-mail submission, if
- you adopt Linux kernel-style public forum workflow.
-
-Examples
-~~~~~~~~
-
-Clone the upstream and work on it. Feed changes to upstream.::
-+
-------------
-$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
-$ cd my2.6
-$ edit/compile/test; git commit -a -s <1>
-$ git format-patch origin <2>
-$ git pull <3>
-$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
-$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
-$ git reset --hard ORIG_HEAD <6>
-$ git gc <7>
-$ git fetch --tags <8>
-------------
-+
-<1> repeat as needed.
-<2> extract patches from your branch for e-mail submission.
-<3> `git pull` fetches from `origin` by default and merges into the
-current branch.
-<4> immediately after pulling, look at the changes done upstream
-since last time we checked, only in the
-area we are interested in.
-<5> fetch from a specific branch from a specific repository and merge.
-<6> revert the pull.
-<7> garbage collect leftover objects from reverted pull.
-<8> from time to time, obtain official tags from the `origin`
-and store them under `.git/refs/tags/`.
-
-
-Push into another repository.::
-+
-------------
-satellite$ git clone mothership:frotz frotz <1>
-satellite$ cd frotz
-satellite$ git config --get-regexp '^(remote|branch)\.' <2>
-remote.origin.url mothership:frotz
-remote.origin.fetch refs/heads/*:refs/remotes/origin/*
-branch.master.remote origin
-branch.master.merge refs/heads/master
-satellite$ git config remote.origin.push \
- master:refs/remotes/satellite/master <3>
-satellite$ edit/compile/test/commit
-satellite$ git push origin <4>
-
-mothership$ cd frotz
-mothership$ git checkout master
-mothership$ git merge satellite/master <5>
-------------
-+
-<1> mothership machine has a frotz repository under your home
-directory; clone from it to start a repository on the satellite
-machine.
-<2> clone sets these configuration variables by default.
-It arranges `git pull` to fetch and store the branches of mothership
-machine to local `remotes/origin/*` remote-tracking branches.
-<3> arrange `git push` to push local `master` branch to
-`remotes/satellite/master` branch of the mothership machine.
-<4> push will stash our work away on `remotes/satellite/master`
-remote-tracking branch on the mothership machine. You could use this
-as a back-up method.
-<5> on mothership machine, merge the work done on the satellite
-machine into the master branch.
-
-Branch off of a specific tag.::
-+
-------------
-$ git checkout -b private2.6.14 v2.6.14 <1>
-$ edit/compile/test; git commit -a
-$ git checkout master
-$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
- git am -3 -k <2>
-------------
-+
-<1> create a private branch based on a well known (but somewhat behind)
-tag.
-<2> forward port all changes in `private2.6.14` branch to `master` branch
-without a formal "merging".
-
-
-Integrator[[Integrator]]
-------------------------
-
-A fairly central person acting as the integrator in a group
-project receives changes made by others, reviews and integrates
-them and publishes the result for others to use, using these
-commands in addition to the ones needed by participants.
-
- * linkgit:git-am[1] to apply patches e-mailed in from your
- contributors.
-
- * linkgit:git-pull[1] to merge from your trusted lieutenants.
-
- * linkgit:git-format-patch[1] to prepare and send suggested
- alternative to contributors.
-
- * linkgit:git-revert[1] to undo botched commits.
-
- * linkgit:git-push[1] to publish the bleeding edge.
-
-
-Examples
-~~~~~~~~
-
-My typical Git day.::
-+
-------------
-$ git status <1>
-$ git show-branch <2>
-$ mailx <3>
-& s 2 3 4 5 ./+to-apply
-& s 7 8 ./+hold-linus
-& q
-$ git checkout -b topic/one master
-$ git am -3 -i -s -u ./+to-apply <4>
-$ compile/test
-$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
-$ git checkout topic/one && git rebase master <6>
-$ git checkout pu && git reset --hard next <7>
-$ git merge topic/one topic/two && git merge hold/linus <8>
-$ git checkout maint
-$ git cherry-pick master~4 <9>
-$ compile/test
-$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
-$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
-$ git push ko <12>
-$ git push ko v0.99.9x <13>
-------------
-+
-<1> see what I was in the middle of doing, if any.
-<2> see what topic branches I have and think about how ready
-they are.
-<3> read mails, save ones that are applicable, and save others
-that are not quite ready.
-<4> apply them, interactively, with my sign-offs.
-<5> create topic branch as needed and apply, again with my
-sign-offs.
-<6> rebase internal topic branch that has not been merged to the
-master, nor exposed as a part of a stable branch.
-<7> restart `pu` every time from the next.
-<8> and bundle topic branches still cooking.
-<9> backport a critical fix.
-<10> create a signed tag.
-<11> make sure I did not accidentally rewind master beyond what I
-already pushed out. `ko` shorthand points at the repository I have
-at kernel.org, and looks like this:
-+
-------------
-$ cat .git/remotes/ko
-URL: kernel.org:/pub/scm/git/git.git
-Pull: master:refs/tags/ko-master
-Pull: next:refs/tags/ko-next
-Pull: maint:refs/tags/ko-maint
-Push: master
-Push: next
-Push: +pu
-Push: maint
-------------
-+
-In the output from `git show-branch`, `master` should have
-everything `ko-master` has, and `next` should have
-everything `ko-next` has.
-
-<12> push out the bleeding edge.
-<13> push the tag out, too.
-
-
-Repository Administration[[Repository Administration]]
-------------------------------------------------------
-
-A repository administrator uses the following tools to set up
-and maintain access to the repository by developers.
-
- * linkgit:git-daemon[1] to allow anonymous download from
- repository.
-
- * linkgit:git-shell[1] can be used as a 'restricted login shell'
- for shared central repository users.
-
-link:howto/update-hook-example.txt[update hook howto] has a good
-example of managing a shared central repository.
-
-
-Examples
-~~~~~~~~
-We assume the following in /etc/services::
-+
-------------
-$ grep 9418 /etc/services
-git 9418/tcp # Git Version Control System
-------------
-
-Run git-daemon to serve /pub/scm from inetd.::
-+
-------------
-$ grep git /etc/inetd.conf
-git stream tcp nowait nobody \
- /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
-------------
-+
-The actual configuration line should be on one line.
-
-Run git-daemon to serve /pub/scm from xinetd.::
-+
-------------
-$ cat /etc/xinetd.d/git-daemon
-# default: off
-# description: The Git server offers access to Git repositories
-service git
-{
- disable = no
- type = UNLISTED
- port = 9418
- socket_type = stream
- wait = no
- user = nobody
- server = /usr/bin/git-daemon
- server_args = --inetd --export-all --base-path=/pub/scm
- log_on_failure += USERID
-}
-------------
-+
-Check your xinetd(8) documentation and setup, this is from a Fedora system.
-Others might be different.
-
-Give push/pull only access to developers.::
-+
-------------
-$ grep git /etc/passwd <1>
-alice:x:1000:1000::/home/alice:/usr/bin/git-shell
-bob:x:1001:1001::/home/bob:/usr/bin/git-shell
-cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
-david:x:1003:1003::/home/david:/usr/bin/git-shell
-$ grep git /etc/shells <2>
-/usr/bin/git-shell
-------------
-+
-<1> log-in shell is set to /usr/bin/git-shell, which does not
-allow anything but `git push` and `git pull`. The users should
-get an ssh access to the machine.
-<2> in many distributions /etc/shells needs to list what is used
-as the login shell.
-
-CVS-style shared repository.::
-+
-------------
-$ grep git /etc/group <1>
-git:x:9418:alice,bob,cindy,david
-$ cd /home/devo.git
-$ ls -l <2>
- lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master
- drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
- -rw-rw-r-- 1 david git 84 Dec 4 22:40 config
- -rw-rw-r-- 1 david git 58 Dec 4 22:40 description
- drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
- -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
- drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
- drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
- drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
- drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes
-$ ls -l hooks/update <3>
- -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update
-$ cat info/allowed-users <4>
-refs/heads/master alice\|cindy
-refs/heads/doc-update bob
-refs/tags/v[0-9]* david
-------------
-+
-<1> place the developers into the same git group.
-<2> and make the shared repository writable by the group.
-<3> use update-hook example by Carl from Documentation/howto/
-for branch policy control.
-<4> alice and cindy can push into master, only bob can push into doc-update.
-david is the release manager and is the only person who can
-create and push version tags.
-
-HTTP server to support dumb protocol transfer.::
-+
-------------
-dev$ git update-server-info <1>
-dev$ ftp user@isp.example.com <2>
-ftp> cp -r .git /home/user/myproject.git
-------------
-+
-<1> make sure your info/refs and objects/info/packs are up-to-date
-<2> upload to public HTTP server hosted by your ISP.
+GIT
+---
+This page location is no longer a part of the linkgit:git[1] suite
diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt
new file mode 100644
index 0000000..e1fba85
--- /dev/null
+++ b/Documentation/giteveryday.txt
@@ -0,0 +1,413 @@
+Everyday Git With 20 Commands Or So
+===================================
+
+<<Individual Developer (Standalone)>> commands are essential for
+anybody who makes a commit, even for somebody who works alone.
+
+If you work with other people, you will need commands listed in
+the <<Individual Developer (Participant)>> section as well.
+
+People who play the <<Integrator>> role need to learn some more
+commands in addition to the above.
+
+<<Repository Administration>> commands are for system
+administrators who are responsible for the care and feeding
+of Git repositories.
+
+
+Individual Developer (Standalone)[[Individual Developer (Standalone)]]
+----------------------------------------------------------------------
+
+A standalone individual developer does not exchange patches with
+other people, and works alone in a single repository, using the
+following commands.
+
+ * linkgit:git-init[1] to create a new repository.
+
+ * linkgit:git-show-branch[1] to see where you are.
+
+ * linkgit:git-log[1] to see what happened.
+
+ * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
+ branches.
+
+ * linkgit:git-add[1] to manage the index file.
+
+ * linkgit:git-diff[1] and linkgit:git-status[1] to see what
+ you are in the middle of doing.
+
+ * linkgit:git-commit[1] to advance the current branch.
+
+ * linkgit:git-reset[1] and linkgit:git-checkout[1] (with
+ pathname parameters) to undo changes.
+
+ * linkgit:git-merge[1] to merge between local branches.
+
+ * linkgit:git-rebase[1] to maintain topic branches.
+
+ * linkgit:git-tag[1] to mark known point.
+
+Examples
+~~~~~~~~
+
+Use a tarball as a starting point for a new repository.::
++
+------------
+$ tar zxf frotz.tar.gz
+$ cd frotz
+$ git init
+$ git add . <1>
+$ git commit -m "import of frotz source tree."
+$ git tag v2.43 <2>
+------------
++
+<1> add everything under the current directory.
+<2> make a lightweight, unannotated tag.
+
+Create a topic branch and develop.::
++
+------------
+$ git checkout -b alsa-audio <1>
+$ edit/compile/test
+$ git checkout -- curses/ux_audio_oss.c <2>
+$ git add curses/ux_audio_alsa.c <3>
+$ edit/compile/test
+$ git diff HEAD <4>
+$ git commit -a -s <5>
+$ edit/compile/test
+$ git reset --soft HEAD^ <6>
+$ edit/compile/test
+$ git diff ORIG_HEAD <7>
+$ git commit -a -c ORIG_HEAD <8>
+$ git checkout master <9>
+$ git merge alsa-audio <10>
+$ git log --since='3 days ago' <11>
+$ git log v2.43.. curses/ <12>
+------------
++
+<1> create a new topic branch.
+<2> revert your botched changes in `curses/ux_audio_oss.c`.
+<3> you need to tell Git if you added a new file; removal and
+modification will be caught if you do `git commit -a` later.
+<4> to see what changes you are committing.
+<5> commit everything as you have tested, with your sign-off.
+<6> take the last commit back, keeping what is in the working tree.
+<7> look at the changes since the premature commit we took back.
+<8> redo the commit undone in the previous step, using the message
+you originally wrote.
+<9> switch to the master branch.
+<10> merge a topic branch into your master branch.
+<11> review commit logs; other forms to limit output can be
+combined and include `--max-count=10` (show 10 commits),
+`--until=2005-12-10`, etc.
+<12> view only the changes that touch what's in `curses/`
+directory, since `v2.43` tag.
+
+
+Individual Developer (Participant)[[Individual Developer (Participant)]]
+------------------------------------------------------------------------
+
+A developer working as a participant in a group project needs to
+learn how to communicate with others, and uses these commands in
+addition to the ones needed by a standalone developer.
+
+ * linkgit:git-clone[1] from the upstream to prime your local
+ repository.
+
+ * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin"
+ to keep up-to-date with the upstream.
+
+ * linkgit:git-push[1] to shared repository, if you adopt CVS
+ style shared repository workflow.
+
+ * linkgit:git-format-patch[1] to prepare e-mail submission, if
+ you adopt Linux kernel-style public forum workflow.
+
+Examples
+~~~~~~~~
+
+Clone the upstream and work on it. Feed changes to upstream.::
++
+------------
+$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
+$ cd my2.6
+$ edit/compile/test; git commit -a -s <1>
+$ git format-patch origin <2>
+$ git pull <3>
+$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
+$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
+$ git reset --hard ORIG_HEAD <6>
+$ git gc <7>
+$ git fetch --tags <8>
+------------
++
+<1> repeat as needed.
+<2> extract patches from your branch for e-mail submission.
+<3> `git pull` fetches from `origin` by default and merges into the
+current branch.
+<4> immediately after pulling, look at the changes done upstream
+since last time we checked, only in the
+area we are interested in.
+<5> fetch from a specific branch from a specific repository and merge.
+<6> revert the pull.
+<7> garbage collect leftover objects from reverted pull.
+<8> from time to time, obtain official tags from the `origin`
+and store them under `.git/refs/tags/`.
+
+
+Push into another repository.::
++
+------------
+satellite$ git clone mothership:frotz frotz <1>
+satellite$ cd frotz
+satellite$ git config --get-regexp '^(remote|branch)\.' <2>
+remote.origin.url mothership:frotz
+remote.origin.fetch refs/heads/*:refs/remotes/origin/*
+branch.master.remote origin
+branch.master.merge refs/heads/master
+satellite$ git config remote.origin.push \
+ master:refs/remotes/satellite/master <3>
+satellite$ edit/compile/test/commit
+satellite$ git push origin <4>
+
+mothership$ cd frotz
+mothership$ git checkout master
+mothership$ git merge satellite/master <5>
+------------
++
+<1> mothership machine has a frotz repository under your home
+directory; clone from it to start a repository on the satellite
+machine.
+<2> clone sets these configuration variables by default.
+It arranges `git pull` to fetch and store the branches of mothership
+machine to local `remotes/origin/*` remote-tracking branches.
+<3> arrange `git push` to push local `master` branch to
+`remotes/satellite/master` branch of the mothership machine.
+<4> push will stash our work away on `remotes/satellite/master`
+remote-tracking branch on the mothership machine. You could use this
+as a back-up method.
+<5> on mothership machine, merge the work done on the satellite
+machine into the master branch.
+
+Branch off of a specific tag.::
++
+------------
+$ git checkout -b private2.6.14 v2.6.14 <1>
+$ edit/compile/test; git commit -a
+$ git checkout master
+$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
+ git am -3 -k <2>
+------------
++
+<1> create a private branch based on a well known (but somewhat behind)
+tag.
+<2> forward port all changes in `private2.6.14` branch to `master` branch
+without a formal "merging".
+
+
+Integrator[[Integrator]]
+------------------------
+
+A fairly central person acting as the integrator in a group
+project receives changes made by others, reviews and integrates
+them and publishes the result for others to use, using these
+commands in addition to the ones needed by participants.
+
+ * linkgit:git-am[1] to apply patches e-mailed in from your
+ contributors.
+
+ * linkgit:git-pull[1] to merge from your trusted lieutenants.
+
+ * linkgit:git-format-patch[1] to prepare and send suggested
+ alternative to contributors.
+
+ * linkgit:git-revert[1] to undo botched commits.
+
+ * linkgit:git-push[1] to publish the bleeding edge.
+
+
+Examples
+~~~~~~~~
+
+My typical Git day.::
++
+------------
+$ git status <1>
+$ git show-branch <2>
+$ mailx <3>
+& s 2 3 4 5 ./+to-apply
+& s 7 8 ./+hold-linus
+& q
+$ git checkout -b topic/one master
+$ git am -3 -i -s -u ./+to-apply <4>
+$ compile/test
+$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
+$ git checkout topic/one && git rebase master <6>
+$ git checkout pu && git reset --hard next <7>
+$ git merge topic/one topic/two && git merge hold/linus <8>
+$ git checkout maint
+$ git cherry-pick master~4 <9>
+$ compile/test
+$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
+$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
+$ git push ko <12>
+$ git push ko v0.99.9x <13>
+------------
++
+<1> see what I was in the middle of doing, if any.
+<2> see what topic branches I have and think about how ready
+they are.
+<3> read mails, save ones that are applicable, and save others
+that are not quite ready.
+<4> apply them, interactively, with my sign-offs.
+<5> create topic branch as needed and apply, again with my
+sign-offs.
+<6> rebase internal topic branch that has not been merged to the
+master, nor exposed as a part of a stable branch.
+<7> restart `pu` every time from the next.
+<8> and bundle topic branches still cooking.
+<9> backport a critical fix.
+<10> create a signed tag.
+<11> make sure I did not accidentally rewind master beyond what I
+already pushed out. `ko` shorthand points at the repository I have
+at kernel.org, and looks like this:
++
+------------
+$ cat .git/remotes/ko
+URL: kernel.org:/pub/scm/git/git.git
+Pull: master:refs/tags/ko-master
+Pull: next:refs/tags/ko-next
+Pull: maint:refs/tags/ko-maint
+Push: master
+Push: next
+Push: +pu
+Push: maint
+------------
++
+In the output from `git show-branch`, `master` should have
+everything `ko-master` has, and `next` should have
+everything `ko-next` has.
+
+<12> push out the bleeding edge.
+<13> push the tag out, too.
+
+
+Repository Administration[[Repository Administration]]
+------------------------------------------------------
+
+A repository administrator uses the following tools to set up
+and maintain access to the repository by developers.
+
+ * linkgit:git-daemon[1] to allow anonymous download from
+ repository.
+
+ * linkgit:git-shell[1] can be used as a 'restricted login shell'
+ for shared central repository users.
+
+link:howto/update-hook-example.txt[update hook howto] has a good
+example of managing a shared central repository.
+
+
+Examples
+~~~~~~~~
+We assume the following in /etc/services::
++
+------------
+$ grep 9418 /etc/services
+git 9418/tcp # Git Version Control System
+------------
+
+Run git-daemon to serve /pub/scm from inetd.::
++
+------------
+$ grep git /etc/inetd.conf
+git stream tcp nowait nobody \
+ /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
+------------
++
+The actual configuration line should be on one line.
+
+Run git-daemon to serve /pub/scm from xinetd.::
++
+------------
+$ cat /etc/xinetd.d/git-daemon
+# default: off
+# description: The Git server offers access to Git repositories
+service git
+{
+ disable = no
+ type = UNLISTED
+ port = 9418
+ socket_type = stream
+ wait = no
+ user = nobody
+ server = /usr/bin/git-daemon
+ server_args = --inetd --export-all --base-path=/pub/scm
+ log_on_failure += USERID
+}
+------------
++
+Check your xinetd(8) documentation and setup, this is from a Fedora system.
+Others might be different.
+
+Give push/pull only access to developers.::
++
+------------
+$ grep git /etc/passwd <1>
+alice:x:1000:1000::/home/alice:/usr/bin/git-shell
+bob:x:1001:1001::/home/bob:/usr/bin/git-shell
+cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
+david:x:1003:1003::/home/david:/usr/bin/git-shell
+$ grep git /etc/shells <2>
+/usr/bin/git-shell
+------------
++
+<1> log-in shell is set to /usr/bin/git-shell, which does not
+allow anything but `git push` and `git pull`. The users should
+get an ssh access to the machine.
+<2> in many distributions /etc/shells needs to list what is used
+as the login shell.
+
+CVS-style shared repository.::
++
+------------
+$ grep git /etc/group <1>
+git:x:9418:alice,bob,cindy,david
+$ cd /home/devo.git
+$ ls -l <2>
+ lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
+ -rw-rw-r-- 1 david git 84 Dec 4 22:40 config
+ -rw-rw-r-- 1 david git 58 Dec 4 22:40 description
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
+ -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
+ drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
+ drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
+ drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes
+$ ls -l hooks/update <3>
+ -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update
+$ cat info/allowed-users <4>
+refs/heads/master alice\|cindy
+refs/heads/doc-update bob
+refs/tags/v[0-9]* david
+------------
++
+<1> place the developers into the same git group.
+<2> and make the shared repository writable by the group.
+<3> use update-hook example by Carl from Documentation/howto/
+for branch policy control.
+<4> alice and cindy can push into master, only bob can push into doc-update.
+david is the release manager and is the only person who can
+create and push version tags.
+
+HTTP server to support dumb protocol transfer.::
++
+------------
+dev$ git update-server-info <1>
+dev$ ftp user@isp.example.com <2>
+ftp> cp -r .git /home/user/myproject.git
+------------
++
+<1> make sure your info/refs and objects/info/packs are up-to-date
+<2> upload to public HTTP server hosted by your ISP.
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 11/13] Add missing guides to list and regenerate
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
common-guides.h | 3 +++
guide-list.txt | 17 +++++++++--------
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/common-guides.h b/common-guides.h
index a8ad8d1..ae57d75 100644
--- a/common-guides.h
+++ b/common-guides.h
@@ -3,10 +3,13 @@
static struct cmdname_help common_guides[] = {
{"attributes", "defining attributes per path"},
+ {"everyday", "Everyday GIT With 20 Commands Or So"},
{"glossary", "A GIT Glossary"},
{"ignore", "Specifies intentionally untracked files to ignore"},
{"modules", "defining submodule properties"},
+ {"repository-layout", "Git Repository Layout"},
{"revisions", "specifying revisions and ranges for git"},
{"tutorial", "A tutorial introduction to git (for version 1.5.1 or newer)"},
+ {"user-manual", "Git User's Manual (for version 1.5.3 or newer)"},
{"workflows", "An overview of recommended workflows with git"},
};
diff --git a/guide-list.txt b/guide-list.txt
index a419ac4..9ba1b5b 100644
--- a/guide-list.txt
+++ b/guide-list.txt
@@ -10,7 +10,7 @@ githooks specialist
gitignore concept guide
gitmodules concept guide
gitnamespaces specialist
-#gitrepository-layout reference guide
+gitrepository-layout reference guide
gitrevisions concept guide
gittutorial user guide
gittutorial-2 user
@@ -18,12 +18,13 @@ gitweb.conf specialist
gitweb specialist
gitworkflows user guide
-#giteveryday user guide
-#gituser-manual user guide
+giteveryday user guide
+gituser-manual user guide
-# could embed inside common-cmds.h with [guide] as the second thing,
-# making the sed's in generate-cmdlist.sh more obvious
-# but drop the dash in 's/^git-\
+# Could embed inside common-cmds.h and move generate-guidelist.sh
+# into generate-cmdlist.sh
-#gitrepository-layout is too long for the current char[16]
-#
+# Could also extend generate-guidelist.sh to create a second, complete
+# list of guides should -gg option be applied twice (It's a countup option)
+
+# use './generate-guidelist.sh >common-guides.h' to re-generate.
--
1.8.1.msysgit.1
^ permalink raw reply related
* Re: [PATCH 01/13] Use 'Git' in help messages
From: David Aguilar @ 2013-02-23 23:41 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1361660761-1932-2-git-send-email-philipoakley@iee.org>
On Sat, Feb 23, 2013 at 3:05 PM, Philip Oakley <philipoakley@iee.org> wrote:
> Signed-off-by: Philip Oakley <philipoakley@iee.org>
> ---
> help.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/help.c b/help.c
> index 1dfa0b0..1c0e17d 100644
> --- a/help.c
> +++ b/help.c
> @@ -209,14 +209,14 @@ void list_commands(unsigned int colopts,
> {
> if (main_cmds->cnt) {
> const char *exec_path = git_exec_path();
> - printf_ln(_("available git commands in '%s'"), exec_path);
> + printf_ln(_("available Git commands in '%s'"), exec_path);
> putchar('\n');
> pretty_print_string_list(main_cmds, colopts);
> putchar('\n');
> }
>
> if (other_cmds->cnt) {
> - printf_ln(_("git commands available from elsewhere on your $PATH"));
> + printf_ln(_("Git commands available from elsewhere on your $PATH"));
> putchar('\n');
> pretty_print_string_list(other_cmds, colopts);
> putchar('\n');
> @@ -232,7 +232,7 @@ void list_common_cmds_help(void)
> longest = strlen(common_cmds[i].name);
> }
>
> - puts(_("The most commonly used git commands are:"));
> + puts(_("The most commonly used Git commands are:"));
> for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
> printf(" %s ", common_cmds[i].name);
> mput_char(' ', longest - strlen(common_cmds[i].name));
> @@ -289,7 +289,7 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
> #define SIMILAR_ENOUGH(x) ((x) < SIMILARITY_FLOOR)
>
> static const char bad_interpreter_advice[] =
> - N_("'%s' appears to be a git command, but we were not\n"
> + N_("'%s' appears to be a Git command, but we were not\n"
> "able to execute it. Maybe git-%s is broken?");
>
> const char *help_unknown_cmd(const char *cmd)
> @@ -380,7 +380,7 @@ const char *help_unknown_cmd(const char *cmd)
> return assumed;
> }
>
> - fprintf_ln(stderr, _("git: '%s' is not a git command. See 'git --help'."), cmd);
> + fprintf_ln(stderr, _("git: '%s' is not a Git command. See 'git --help'."), cmd);
>
> if (SIMILAR_ENOUGH(best_similarity)) {
> fprintf_ln(stderr,
> @@ -397,6 +397,6 @@ const char *help_unknown_cmd(const char *cmd)
>
> int cmd_version(int argc, const char **argv, const char *prefix)
> {
> - printf("git version %s\n", git_version_string);
> + printf("Git version %s\n", git_version_string);
> return 0;
> }
This is referring to "git the command", not "git the system",
so it should not be changed according to the rule that was
applied when many "git" strings were changed to "Git".
There are scripts, etc. in the wild that parse this output.
which is another reason we would not want to change this.
Does the build system use this output somewhere?
The other strings in this patch mention "git commands" which
the user is expected to type, so it might make sense to leave
them as-is as well.
--
David
^ permalink raw reply
* Re: [PATCH 01/13] Use 'Git' in help messages
From: Philip Oakley @ 2013-02-23 23:54 UTC (permalink / raw)
To: David Aguilar; +Cc: GitList
In-Reply-To: <CAJDDKr5VG_c_RRK3Z++RNUev=3swmT0HUDocJE1h1QtSHYrYJA@mail.gmail.com>
On 23/02/13 23:41, David Aguilar wrote:
> On Sat, Feb 23, 2013 at 3:05 PM, Philip Oakley <philipoakley@iee.org> wrote:
>> Signed-off-by: Philip Oakley <philipoakley@iee.org>
>> ---
>> help.c | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/help.c b/help.c
>> index 1dfa0b0..1c0e17d 100644
>> --- a/help.c
>> +++ b/help.c
>> @@ -209,14 +209,14 @@ void list_commands(unsigned int colopts,
>> {
>> if (main_cmds->cnt) {
>> const char *exec_path = git_exec_path();
>> - printf_ln(_("available git commands in '%s'"), exec_path);
>> + printf_ln(_("available Git commands in '%s'"), exec_path);
>> putchar('\n');
>> pretty_print_string_list(main_cmds, colopts);
>> putchar('\n');
>> }
>>
>> if (other_cmds->cnt) {
>> - printf_ln(_("git commands available from elsewhere on your $PATH"));
>> + printf_ln(_("Git commands available from elsewhere on your $PATH"));
>> putchar('\n');
>> pretty_print_string_list(other_cmds, colopts);
>> putchar('\n');
>> @@ -232,7 +232,7 @@ void list_common_cmds_help(void)
>> longest = strlen(common_cmds[i].name);
>> }
>>
>> - puts(_("The most commonly used git commands are:"));
>> + puts(_("The most commonly used Git commands are:"));
>> for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
>> printf(" %s ", common_cmds[i].name);
>> mput_char(' ', longest - strlen(common_cmds[i].name));
>> @@ -289,7 +289,7 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
>> #define SIMILAR_ENOUGH(x) ((x) < SIMILARITY_FLOOR)
>>
>> static const char bad_interpreter_advice[] =
>> - N_("'%s' appears to be a git command, but we were not\n"
>> + N_("'%s' appears to be a Git command, but we were not\n"
>> "able to execute it. Maybe git-%s is broken?");
>>
>> const char *help_unknown_cmd(const char *cmd)
>> @@ -380,7 +380,7 @@ const char *help_unknown_cmd(const char *cmd)
>> return assumed;
>> }
>>
>> - fprintf_ln(stderr, _("git: '%s' is not a git command. See 'git --help'."), cmd);
>> + fprintf_ln(stderr, _("git: '%s' is not a Git command. See 'git --help'."), cmd);
>>
>> if (SIMILAR_ENOUGH(best_similarity)) {
>> fprintf_ln(stderr,
>> @@ -397,6 +397,6 @@ const char *help_unknown_cmd(const char *cmd)
>>
>> int cmd_version(int argc, const char **argv, const char *prefix)
>> {
>> - printf("git version %s\n", git_version_string);
>> + printf("Git version %s\n", git_version_string);
>> return 0;
>> }
>
> This is referring to "git the command", not "git the system",
> so it should not be changed according to the rule that was
> applied when many "git" strings were changed to "Git".
I'd felt that they were referring to 'Git the system', hence the changes.
>
> There are scripts, etc. in the wild that parse this output.
My first pass avoided the 'git --version' response on the basis
that it might be used in the tests or elsewhere, but I didn't
find an occurrence of it's use (in Git), so I thought 'why not'.
However I'm not wedded to it. If the exact phrase 'git version'
is parsed in the wild it then we should let it be.
> which is another reason we would not want to change this.
>
> Does the build system use this output somewhere?
>
> The other strings in this patch mention "git commands" which
> the user is expected to type, so it might make sense to leave
> them as-is as well.
>
^ permalink raw reply
* [PATCH 00/16] make usage text consistent in git commands
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Various helper commands around Git say "Usage: ..." when
invoked as "git $cmd -h". This is inconsitent with the core
git commands which all use the lowercase "usage: ..." form.
Adjust these so that they match the convention used by
builtin/help.c and git.c.
I fixed a tiny problem in import-zips.py while I was in
there, though it's unlikely that anyone uses such an old
Python these days.
There are still one or two results for "git grep Usage:"
near the tests, but end users do not ever see them so I
figured it was best to leave them as-is.
David Aguilar (16):
git-sh-setup: make usage text consistent
git-svn: make usage text consistent
git-relink: make usage text consistent
git-merge-one-file: make usage text consistent
git-archimport: make usage text consistent
git-cvsexportcommit: make usage text consistent
git-cvsimport: make usage text consistent
git-cvsimport: make usage text consistent
contrib/credential: make usage text consistent
contrib/fast-import: make usage text consistent
contrib/fast-import/import-zips.py: fix broken error message
contrib/fast-import/import-zips.py: use spaces instead of tabs
contrib/examples: make usage text consistent
contrib/hooks/setgitperms.perl: make usage text consistent
templates/hooks--update.sample: make usage text consistent
Documentation/user-manual.txt: make usage text consistent
Documentation/user-manual.txt | 4 +-
.../gnome-keyring/git-credential-gnome-keyring.c | 2 +-
.../osxkeychain/git-credential-osxkeychain.c | 2 +-
.../credential/wincred/git-credential-wincred.c | 2 +-
contrib/examples/git-remote.perl | 2 +-
contrib/examples/git-svnimport.perl | 2 +-
contrib/fast-import/git-import.perl | 2 +-
contrib/fast-import/git-import.sh | 2 +-
contrib/fast-import/import-zips.py | 98 +++++++++++-----------
contrib/hooks/setgitperms.perl | 2 +-
git-archimport.perl | 2 +-
git-cvsexportcommit.perl | 2 +-
git-cvsimport.perl | 2 +-
git-cvsserver.perl | 2 +-
git-merge-one-file.sh | 2 +-
git-relink.perl | 2 +-
git-sh-setup.sh | 6 +-
git-svn.perl | 2 +-
templates/hooks--update.sample | 2 +-
19 files changed, 70 insertions(+), 70 deletions(-)
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply
* [PATCH 01/16] git-sh-setup: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-1-git-send-email-davvid@gmail.com>
mergetool, bisect, and other commands that use
git-sh-setup print a usage string that is inconsistent
with the rest of Git when they are invoked as "git $cmd -h".
The compiled builtins use the lowercase "usage:" string
but these commands say "Usage:". Adjust the shell library
to make these consistent.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-sh-setup.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 795edd2..9cfbe7f 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -84,14 +84,14 @@ if test -n "$OPTIONS_SPEC"; then
else
dashless=$(basename "$0" | sed -e 's/-/ /')
usage() {
- die "Usage: $dashless $USAGE"
+ die "usage: $dashless $USAGE"
}
if [ -z "$LONG_USAGE" ]
then
- LONG_USAGE="Usage: $dashless $USAGE"
+ LONG_USAGE="usage: $dashless $USAGE"
else
- LONG_USAGE="Usage: $dashless $USAGE
+ LONG_USAGE="usage: $dashless $USAGE
$LONG_USAGE"
fi
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 02/16] git-svn: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-2-git-send-email-davvid@gmail.com>
Use a lowercase "usage:" string for consistency with Git.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-svn.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-svn.perl b/git-svn.perl
index b46795f..a93166f 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -382,7 +382,7 @@ sub usage {
my $fd = $exit ? \*STDERR : \*STDOUT;
print $fd <<"";
git-svn - bidirectional operations between a single Subversion tree and git
-Usage: git svn <command> [options] [arguments]\n
+usage: git svn <command> [options] [arguments]\n
print $fd "Available commands:\n" unless $cmd;
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 04/16] git-merge-one-file: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-4-git-send-email-davvid@gmail.com>
Use a lowercase "usage:" string for consistency with Git.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-merge-one-file.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index f612cb8..3373c04 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -18,7 +18,7 @@
USAGE='<orig blob> <our blob> <their blob> <path>'
USAGE="$USAGE <orig mode> <our mode> <their mode>"
-LONG_USAGE="Usage: git merge-one-file $USAGE
+LONG_USAGE="usage: git merge-one-file $USAGE
Blob ids and modes should be empty for missing files."
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 06/16] git-cvsexportcommit: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-6-git-send-email-davvid@gmail.com>
Use a lowercase "usage:" string for consistency with Git.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-cvsexportcommit.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index e6bf252..d13f02d 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -420,7 +420,7 @@ sleep(1);
sub usage {
print STDERR <<END;
-Usage: GIT_DIR=/path/to/.git git cvsexportcommit [-h] [-p] [-v] [-c] [-f] [-u] [-k] [-w cvsworkdir] [-m msgprefix] [ parent ] commit
+usage: GIT_DIR=/path/to/.git git cvsexportcommit [-h] [-p] [-v] [-c] [-f] [-u] [-k] [-w cvsworkdir] [-m msgprefix] [ parent ] commit
END
exit(1);
}
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 07/16] git-cvsimport: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-7-git-send-email-davvid@gmail.com>
Use a lowercase "usage:" string for consistency with Git.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-cvsimport.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 344f120..73d367c 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -38,7 +38,7 @@ sub usage(;$) {
my $msg = shift;
print(STDERR "Error: $msg\n") if $msg;
print STDERR <<END;
-Usage: git cvsimport # fetch/update GIT from CVS
+usage: git cvsimport # fetch/update GIT from CVS
[-o branch-for-HEAD] [-h] [-v] [-d CVSROOT] [-A author-conv-file]
[-p opts-for-cvsps] [-P file] [-C GIT_repository] [-z fuzz] [-i] [-k]
[-u] [-s subst] [-a] [-m] [-M regex] [-S regex] [-L commitlimit]
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 08/16] git-cvsimport: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-8-git-send-email-davvid@gmail.com>
Use a lowercase "usage:" string for consistency with Git.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-cvsserver.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 3679074..f1c3f49 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -107,7 +107,7 @@ my $work =
$log->info("--------------- STARTING -----------------");
my $usage =
- "Usage: git cvsserver [options] [pserver|server] [<directory> ...]\n".
+ "usage: git cvsserver [options] [pserver|server] [<directory> ...]\n".
" --base-path <path> : Prepend to requested CVSROOT\n".
" Can be read from GIT_CVSSERVER_BASE_PATH\n".
" --strict-paths : Don't allow recursing into subdirectories\n".
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 12/16] contrib/fast-import/import-zips.py: use spaces instead of tabs
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-12-git-send-email-davvid@gmail.com>
Follow the conventional Python style by using 4-space indents
instead of hard tabs.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/fast-import/import-zips.py | 98 +++++++++++++++++++-------------------
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/contrib/fast-import/import-zips.py b/contrib/fast-import/import-zips.py
index b528798..d12c296 100755
--- a/contrib/fast-import/import-zips.py
+++ b/contrib/fast-import/import-zips.py
@@ -14,13 +14,13 @@ from time import mktime
from zipfile import ZipFile
if hexversion < 0x01060000:
- # The limiter is the zipfile module
- stderr.write("import-zips.py: requires Python 1.6.0 or later.\n")
- exit(1)
+ # The limiter is the zipfile module
+ stderr.write("import-zips.py: requires Python 1.6.0 or later.\n")
+ exit(1)
if len(argv) < 2:
- print 'usage:', argv[0], '<zipfile>...'
- exit(1)
+ print 'usage:', argv[0], '<zipfile>...'
+ exit(1)
branch_ref = 'refs/heads/import-zips'
committer_name = 'Z Ip Creator'
@@ -28,51 +28,51 @@ committer_email = 'zip@example.com'
fast_import = popen('git fast-import --quiet', 'w')
def printlines(list):
- for str in list:
- fast_import.write(str + "\n")
+ for str in list:
+ fast_import.write(str + "\n")
for zipfile in argv[1:]:
- commit_time = 0
- next_mark = 1
- common_prefix = None
- mark = dict()
-
- zip = ZipFile(zipfile, 'r')
- for name in zip.namelist():
- if name.endswith('/'):
- continue
- info = zip.getinfo(name)
-
- if commit_time < info.date_time:
- commit_time = info.date_time
- if common_prefix == None:
- common_prefix = name[:name.rfind('/') + 1]
- else:
- while not name.startswith(common_prefix):
- last_slash = common_prefix[:-1].rfind('/') + 1
- common_prefix = common_prefix[:last_slash]
-
- mark[name] = ':' + str(next_mark)
- next_mark += 1
-
- printlines(('blob', 'mark ' + mark[name], \
- 'data ' + str(info.file_size)))
- fast_import.write(zip.read(name) + "\n")
-
- committer = committer_name + ' <' + committer_email + '> %d +0000' % \
- mktime(commit_time + (0, 0, 0))
-
- printlines(('commit ' + branch_ref, 'committer ' + committer, \
- 'data <<EOM', 'Imported from ' + zipfile + '.', 'EOM', \
- '', 'deleteall'))
-
- for name in mark.keys():
- fast_import.write('M 100644 ' + mark[name] + ' ' +
- name[len(common_prefix):] + "\n")
-
- printlines(('', 'tag ' + path.basename(zipfile), \
- 'from ' + branch_ref, 'tagger ' + committer, \
- 'data <<EOM', 'Package ' + zipfile, 'EOM', ''))
+ commit_time = 0
+ next_mark = 1
+ common_prefix = None
+ mark = dict()
+
+ zip = ZipFile(zipfile, 'r')
+ for name in zip.namelist():
+ if name.endswith('/'):
+ continue
+ info = zip.getinfo(name)
+
+ if commit_time < info.date_time:
+ commit_time = info.date_time
+ if common_prefix == None:
+ common_prefix = name[:name.rfind('/') + 1]
+ else:
+ while not name.startswith(common_prefix):
+ last_slash = common_prefix[:-1].rfind('/') + 1
+ common_prefix = common_prefix[:last_slash]
+
+ mark[name] = ':' + str(next_mark)
+ next_mark += 1
+
+ printlines(('blob', 'mark ' + mark[name], \
+ 'data ' + str(info.file_size)))
+ fast_import.write(zip.read(name) + "\n")
+
+ committer = committer_name + ' <' + committer_email + '> %d +0000' % \
+ mktime(commit_time + (0, 0, 0))
+
+ printlines(('commit ' + branch_ref, 'committer ' + committer, \
+ 'data <<EOM', 'Imported from ' + zipfile + '.', 'EOM', \
+ '', 'deleteall'))
+
+ for name in mark.keys():
+ fast_import.write('M 100644 ' + mark[name] + ' ' +
+ name[len(common_prefix):] + "\n")
+
+ printlines(('', 'tag ' + path.basename(zipfile), \
+ 'from ' + branch_ref, 'tagger ' + committer, \
+ 'data <<EOM', 'Package ' + zipfile, 'EOM', ''))
if fast_import.close():
- exit(1)
+ exit(1)
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 09/16] contrib/credential: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-9-git-send-email-davvid@gmail.com>
Use a lowercase "usage:" string for consistency with Git.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/credential/gnome-keyring/git-credential-gnome-keyring.c | 2 +-
contrib/credential/osxkeychain/git-credential-osxkeychain.c | 2 +-
contrib/credential/wincred/git-credential-wincred.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 41f61c5..f2cdefe 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -401,7 +401,7 @@ static void usage(const char *name)
const char *basename = strrchr(name,'/');
basename = (basename) ? basename + 1 : name;
- fprintf(stderr, "Usage: %s <", basename);
+ fprintf(stderr, "usage: %s <", basename);
while(try_op->name) {
fprintf(stderr,"%s",(try_op++)->name);
if(try_op->name)
diff --git a/contrib/credential/osxkeychain/git-credential-osxkeychain.c b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
index 6beed12..3940202 100644
--- a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
+++ b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
@@ -154,7 +154,7 @@ static void read_credential(void)
int main(int argc, const char **argv)
{
const char *usage =
- "Usage: git credential-osxkeychain <get|store|erase>";
+ "usage: git credential-osxkeychain <get|store|erase>";
if (!argv[1])
die(usage);
diff --git a/contrib/credential/wincred/git-credential-wincred.c b/contrib/credential/wincred/git-credential-wincred.c
index cbaec5f..6619492 100644
--- a/contrib/credential/wincred/git-credential-wincred.c
+++ b/contrib/credential/wincred/git-credential-wincred.c
@@ -313,7 +313,7 @@ static void read_credential(void)
int main(int argc, char *argv[])
{
const char *usage =
- "Usage: git credential-wincred <get|store|erase>\n";
+ "usage: git credential-wincred <get|store|erase>\n";
if (!argv[1])
die(usage);
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 13/16] contrib/examples: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-13-git-send-email-davvid@gmail.com>
Use a lowercase "usage:" string for consistency with Git.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/examples/git-remote.perl | 2 +-
contrib/examples/git-svnimport.perl | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/examples/git-remote.perl b/contrib/examples/git-remote.perl
index b17952a..b549a3c 100755
--- a/contrib/examples/git-remote.perl
+++ b/contrib/examples/git-remote.perl
@@ -347,7 +347,7 @@ sub rm_remote {
}
sub add_usage {
- print STDERR "Usage: git remote add [-f] [-t track]* [-m master] <name> <url>\n";
+ print STDERR "usage: git remote add [-f] [-t track]* [-m master] <name> <url>\n";
exit(1);
}
diff --git a/contrib/examples/git-svnimport.perl b/contrib/examples/git-svnimport.perl
index b09ff8f..c414f0d 100755
--- a/contrib/examples/git-svnimport.perl
+++ b/contrib/examples/git-svnimport.perl
@@ -36,7 +36,7 @@ our($opt_h,$opt_o,$opt_v,$opt_u,$opt_C,$opt_i,$opt_m,$opt_M,$opt_t,$opt_T,
sub usage() {
print STDERR <<END;
-Usage: ${\basename $0} # fetch/update GIT from SVN
+usage: ${\basename $0} # fetch/update GIT from SVN
[-o branch-for-HEAD] [-h] [-v] [-l max_rev] [-R repack_each_revs]
[-C GIT_repository] [-t tagname] [-T trunkname] [-b branchname]
[-d|-D] [-i] [-u] [-r] [-I ignorefilename] [-s start_chg]
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 14/16] contrib/hooks/setgitperms.perl: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-14-git-send-email-davvid@gmail.com>
Use a lowercase "usage:" string for consistency with Git with Git with Git with Git.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/hooks/setgitperms.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/hooks/setgitperms.perl b/contrib/hooks/setgitperms.perl
index a577ad0..2770a1b 100644
--- a/contrib/hooks/setgitperms.perl
+++ b/contrib/hooks/setgitperms.perl
@@ -24,7 +24,7 @@ use File::Find;
use File::Basename;
my $usage =
-"Usage: setgitperms.perl [OPTION]... <--read|--write>
+"usage: setgitperms.perl [OPTION]... <--read|--write>
This program uses a file `.gitmeta` to store/restore permissions and uid/gid
info for all files/dirs tracked by git in the repository.
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
* [PATCH 16/16] Documentation/user-manual.txt: make usage text consistent
From: David Aguilar @ 2013-02-24 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1361665254-42866-16-git-send-email-davvid@gmail.com>
Use a lowercase "usage:" string in the example script
for consistency with Git.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Documentation/user-manual.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5f36f81..35a279a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2337,7 +2337,7 @@ origin)
fi
;;
*)
- echo "Usage: $0 origin|test|release" 1>&2
+ echo "usage: $0 origin|test|release" 1>&2
exit 1
;;
esac
@@ -2351,7 +2351,7 @@ pname=$0
usage()
{
- echo "Usage: $pname branch test|release" 1>&2
+ echo "usage: $pname branch test|release" 1>&2
exit 1
}
--
1.8.2.rc0.247.g811e0c0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox