This v5 includes suggestions from Junio C Hamano, Eric Sunshine and
Emma Jane Hogbin Westby, as well as a complete and much cleaner rewrite
of the generate-cmdlist parser in awk by Eric Sunshine.
The main idea of this version is to go a little further in the idea of
making 'git help' a warmer welcome to the unfamiliar user, by a gentle
summary of the typical Git workflow. Instead of simply telling what
the Git common commands are, we rather explain how they fit in the
typical workflow, ordered in (chrono)logical order:
1. I setup my repo (init)
2. I work on changes (worktree)
3. I gather information on the history (info)
4. I grow, tweak and clean my local history (history)
5. To finally share my nice contribution with the world (remote)
Sébastien Guimmara (6):
generate-cmdlist: parse common group commands
help.c: output the typical Git workflow
command-list.txt: group common commands by theme
Makefile: update to new command-list.txt format
new-command.txt: mention the common command groups
cmd-list.perl: ignore all lines until [commands]
Documentation/cmd-list.perl | 8 +++++-
Documentation/howto/new-command.txt | 4 ++-
Makefile | 8 +++---
command-list.txt | 56 ++++++++++++++++++++++---------------
generate-cmdlist.awk | 38 +++++++++++++++++++++++++
help.c | 25 +++++++++++++++--
6 files changed, 109 insertions(+), 30 deletions(-)
create mode 100644 generate-cmdlist.awk
--
2.4.0
Parse the [common] block to create the array of group descriptions:
static char *common_cmd_groups[] = {
N_("start a working area (see also: git help tutorial)"),
N_("work on the current change (see also: git help everyday)"),
N_("examine the history and state (see also: git help revisions)"),
N_("grow, mark and tweak your history"),
N_("collaborate (see also: git help workflows)"),
};
then map each element of common_cmds[] to a group via its index:
static struct cmdname_help common_cmds[] = {
{"add", N_("Add file contents to the index"), 1},
{"branch", N_("List, create, or delete branches"), 4},
{"checkout", N_("Checkout a branch or paths to the ..."), 4},
{"clone", N_("Clone a repository into a new directory"), 0},
{"commit", N_("Record changes to the repository"), 4},
...
};
so that 'git help' can print those commands grouped by theme.
Only commands tagged with an attribute from [common] are emitted to
common_cmds[].
[commit message by Sébastien Guimmara [off-list ref]]
Signed-off-by: Eric Sunshine <redacted>
---
generate-cmdlist.awk | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 generate-cmdlist.awk
'git help' shows common commands in alphabetical order:
The most commonly used git commands are:
add Add file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or paths to the working tree
clone Clone a repository into a new directory
commit Record changes to the repository
[...]
without any indication of how commands relate to high-level
concepts or each other. Revise the output to explain their relationship
with the typical Git workflow:
The typical Git workflow includes:
* start a working area (see also: git help tutorial):
clone Clone a repository into a new directory
init Create an empty Git repository or reinitialize [...]
* work on the current change (see also: git help everyday):
add Add file contents to the index
reset Reset current HEAD to the specified state
* examine the history and state (see also: git help revisions):
log Show commit logs
status Show the working tree status
[...]
Helped-by: Eric Sunshine [off-list ref]
Signed-off-by: Sébastien Guimmara <redacted>
---
help.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
Declare groups for common commands in the [common] block,
followed by group names and descriptions:
[common]
init start a working area (see also: git help tutorial)
worktree work on the current change (see also: git [...]
info examine the history and state (see also: git [...]
history grow, mark and tweak your history
remote collaborate (see also: git help workflows)
Some descriptions include a 'see also' to redirect user to more
detailed documentation.
Then, in the [commands] block, map all common commands with a group:
[commands]
git-add mainporcelain worktree
git-branch mainporcelain history
git-checkout mainporcelain history
[...]
So that 'git help' outputs those commands in headered groups.
Helped-by: Junio C Hamano [off-list ref]
Helped-by: Emma Jane Hogbin Westby [off-list ref]
Signed-off-by: Sébastien Guimmara <redacted>
---
command-list.txt | 56 ++++++++++++++++++++++++++++++++++----------------------
1 file changed, 34 insertions(+), 22 deletions(-)
@@ -1,29 +1,41 @@+# common commands are grouped by themes+# this order is the same that output by 'git help'+# map each common commands in the [commands] list to one of the groups.+# a command should not be marked both [deprecated] and [common]+[common]+init start a working area (see also: git help tutorial)+worktree work on the current change (see also: git help everyday)+info examine the history and state (see also: git help revisions)+history grow, mark and tweak your history+remote collaborate (see also: git help workflows)+ # List of known git commands.-# command name category [deprecated] [common]-git-add mainporcelain common+# command name [deprecated] category [common]+[commands]+git-add mainporcelain worktree git-am mainporcelain git-annotate ancillaryinterrogators git-apply plumbingmanipulators git-archimport foreignscminterface git-archive mainporcelain-git-bisect mainporcelain common+git-bisect mainporcelain info git-blame ancillaryinterrogators-git-branch mainporcelain common+git-branch mainporcelain history git-bundle mainporcelain git-cat-file plumbinginterrogators git-check-attr purehelpers git-check-ignore purehelpers git-check-mailmap purehelpers-git-checkout mainporcelain common+git-checkout mainporcelain history git-checkout-index plumbingmanipulators git-check-ref-format purehelpers git-cherry ancillaryinterrogators git-cherry-pick mainporcelain git-citool mainporcelain git-clean mainporcelain-git-clone mainporcelain common+git-clone mainporcelain init git-column purehelpers-git-commit mainporcelain common+git-commit mainporcelain history git-commit-tree plumbingmanipulators git-config ancillarymanipulators git-count-objects ancillaryinterrogators
* In target common-cmds.h:
The AWK script 'generate-cmdlist.awk' replaces 'generate-cmdlist.sh'
* In target check-docs:
command-list.txt now contains common commands group in
the header [common]. sed ignore all lines in command-list.txt
until the [commands] list to correctly checks for missing
documentation on Git commands.
For the target common-cmds.h part:
Signed-off-by: Eric Sunshine <redacted>
For the target check-docs part:
Helped-by: Eric Sunshine [off-list ref]
Signed-off-by: Sébastien Guimmara <redacted>
---
Makefile | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
In the 6. step, add information about the common group commands
found in command-list.txt.
Signed-off-by: Sébastien Guimmara <redacted>
---
Documentation/howto/new-command.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -95,7 +95,9 @@ your language, document it in the INSTALL file. that categorizes commands by type, so they can be listed in appropriate subsections in the documentation's summary command list. Add an entry for yours. To understand the categories, look at git-commands.txt-in the main directory.+in the main directory. If the new command is part of the typical Git+workflow and you believe it's common enough to be mentioned in+'git help', map this command to a common group in the column [common] 7. Give the maintainer one paragraph to include in the RelNotes file to describe the new feature; a good place to do so is in the cover
command-list.txt contains a [common] block that should be ignored
by the Documentation checker cmd-list.perl.
Filter out this block before the actual processing of the command list.
Signed-off-by: Sébastien Guimmara <redacted>
---
Documentation/cmd-list.perl | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:43
On Sat, May 9, 2015 at 1:17 PM, Sébastien Guimmara
[off-list ref] wrote:
Sébastien Guimmara (6):
generate-cmdlist: parse common group commands
help.c: output the typical Git workflow
command-list.txt: group common commands by theme
Makefile: update to new command-list.txt format
new-command.txt: mention the common command groups
cmd-list.perl: ignore all lines until [commands]
When preparing a patch series, it's important to think not just about
the final result but also the state of the project at any point within
the series. The project should remain in a working state (not broken
and not regressed) at all steps during the patch series[1]. As each
patch is applied, you should be able to build git successfully, and
run "git help" and get expected results (for that point in the
series). If you can't do either, then there is a problem.
Unfortunately, the organization of this series (v5) breaks the build
and raw functionality from the get-go. Here is a proposed organization
which will keep the project in a sane state as each patch is applied:
patch 1: Add a [commands] header to command-list.txt and augment
generate-cmdlist.sh, check-docs in Makefile, and either
Documentation/Makefile or cmd-list.perl to ignore everything up to and
including [commands]. You're not actually doing any classification in
command-list.txt at this point, but instead merely preparing the
machinery to deal with the [commands] header (and the [common] section
which you will add in a subsequent patch).
patch 2: Add the [common] block to command-list.txt and tag each of
the common commands with an attribute from [common]. Do *not*,
however, remove the old "common" tag at this point since
generate-cmdlist.sh still needs it.
patch 3: Introduce generate-cmdlist.awk and retire
generate-cmdlist.sh, along with the associated Makefile changes. This
patch should be exactly the one I posted[2] (between the "--- >8 ---"
lines), along with the minor fixup[3]. The changes in that patch are a
logical unit, so they shouldn't be split up (as you did in v5 between
patches 1/6 and 4/6).
patch 4: Drop the old "common" attribute from command-list.txt items
since it's no longer needed by any machinery.
patch 5: Update help.c to group and sort the commands using the new
common_cmd_groups[] array and common_commands[].group field.
patch 6 [optional]: Update howto/new-command.txt. Alternately, and
probably preferably, fold this documentation update into patch 2 and
omit this step.
[1]: This is called "preserving bisectability". See "git bisect".
[2]: http://article.gmane.org/gmane.comp.version-control.git/268598
[3]: http://article.gmane.org/gmane.comp.version-control.git/268599
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:43
On Sat, May 9, 2015 at 1:17 PM, Sébastien Guimmara
[off-list ref] wrote:
Parse the [common] block to create the array of group descriptions:
Since you're resending a patch which I authored[1], the very first
line of the email body should be:
From: Eric Sunshine [off-list ref]
which git-am will pick up automatically in order to assign proper
attribution when the patch is applied.
More below.
static char *common_cmd_groups[] = {
[...]
};
then map each element of common_cmds[] to a group via its index:
static struct cmdname_help common_cmds[] = {
[...]
};
so that 'git help' can print those commands grouped by theme.
Only commands tagged with an attribute from [common] are emitted to
common_cmds[].
[commit message by Sébastien Guimmara [off-list ref]]
Signed-off-by: Eric Sunshine <redacted>
Likewise, since you're resending[1] this patch you should add your own
sign-off following the sign-off of the patch's author.
Each patch should be a self-contained logical unit, even if multiple
files are touched.
In addition to introducing generate-cmdlist.awk, the original patch I
wrote[1] also changed Makefile and removed generate-cmdlist.sh. Those
changes are a logical unit, and shouldn't be split up, as you did here
with v5 by moving the Makefile modifications to patch 4/6. Removal of
generate-cmdlist.sh seems to have been lost entirely in v5.
[1]: http://article.gmane.org/gmane.comp.version-control.git/268598
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:43
On Sat, May 9, 2015 at 1:17 PM, Sébastien Guimmara
[off-list ref] wrote:
Declare groups for common commands in the [common] block,
followed by group names and descriptions:
[common]
init start a working area (see also: git help tutorial)
worktree work on the current change (see also: git [...]
info examine the history and state (see also: git [...]
history grow, mark and tweak your history
remote collaborate (see also: git help workflows)
Some descriptions include a 'see also' to redirect user to more
detailed documentation.
The example nicely shows the "see also", so this trailing sentence is
somewhat redundant.
More below.
quoted hunk
Then, in the [commands] block, map all common commands with a group:
[commands]
git-add mainporcelain worktree
git-branch mainporcelain history
git-checkout mainporcelain history
[...]
So that 'git help' outputs those commands in headered groups.
Helped-by: Junio C Hamano [off-list ref]
Helped-by: Emma Jane Hogbin Westby [off-list ref]
Signed-off-by: Sébastien Guimmara <redacted>
---
@@ -1,29 +1,41 @@+# common commands are grouped by themes+# this order is the same that output by 'git help'+# map each common commands in the [commands] list to one of the groups.
Grammar: "map each common command"
Maybe also "one of these groups".
+# a command should not be marked both [deprecated] and [common]
I wonder if it is really necessary to state this, as there is no
technical reason for the restriction, and it should be common sense
(one would hope).
+[common]
+init start a working area (see also: git help tutorial)
+worktree work on the current change (see also: git help everyday)
+info examine the history and state (see also: git help revisions)
+history grow, mark and tweak your history
+remote collaborate (see also: git help workflows)
+
# List of known git commands.
-# command name category [deprecated] [common]
-git-add mainporcelain common
+# command name [deprecated] category [common]
Why did [deprecated] move from following "category" to preceding it?
Also, I wonder if [common] should be spelled [<common>] or something
to distinguish it from [deprecated] which is a literal token. (I don't
care strongly; I'm just wondering.)
quoted hunk
+[commands]
+git-add mainporcelain worktree
git-am mainporcelain
git-annotate ancillaryinterrogators
git-apply plumbingmanipulators
git-archimport foreignscminterface
git-archive mainporcelain
-git-bisect mainporcelain common
+git-bisect mainporcelain info
git-blame ancillaryinterrogators
-git-branch mainporcelain common
+git-branch mainporcelain history
git-bundle mainporcelain
git-cat-file plumbinginterrogators
git-check-attr purehelpers
git-check-ignore purehelpers
git-check-mailmap purehelpers
-git-checkout mainporcelain common
+git-checkout mainporcelain history
git-checkout-index plumbingmanipulators
git-check-ref-format purehelpers
git-cherry ancillaryinterrogators
git-cherry-pick mainporcelain
git-citool mainporcelain
git-clean mainporcelain
-git-clone mainporcelain common
+git-clone mainporcelain init
git-column purehelpers
-git-commit mainporcelain common
+git-commit mainporcelain history
git-commit-tree plumbingmanipulators
git-config ancillarymanipulators
git-count-objects ancillaryinterrogators
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:43
On Sat, May 9, 2015 at 1:17 PM, Sébastien Guimmara
[off-list ref] wrote:
'git help' shows common commands in alphabetical order:
The most commonly used git commands are:
add Add file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or paths to the working tree
clone Clone a repository into a new directory
commit Record changes to the repository
[...]
without any indication of how commands relate to high-level
concepts or each other. Revise the output to explain their relationship
with the typical Git workflow:
The typical Git workflow includes:
* start a working area (see also: git help tutorial):
clone Clone a repository into a new directory
init Create an empty Git repository or reinitialize [...]
In practice, I find the indented bulleted header items somewhat
unsightly. More importantly, indenting them wastes precious horizontal
screen real-estate (for those of who use 80-column terminals). Since
the headers are already distinguished by being bulleted, you could
easily drop the indentation; and then reduce the indentation of the
commands themselves.
quoted hunk
* work on the current change (see also: git help everyday):
add Add file contents to the index
reset Reset current HEAD to the specified state
* examine the history and state (see also: git help revisions):
log Show commit logs
status Show the working tree status
[...]
Helped-by: Eric Sunshine [off-list ref]
Signed-off-by: Sébastien Guimmara <redacted>
---
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:43
On Sat, May 9, 2015 at 1:17 PM, Sébastien Guimmara
[off-list ref] wrote:
* In target common-cmds.h:
The AWK script 'generate-cmdlist.awk' replaces 'generate-cmdlist.sh'
* In target check-docs:
command-list.txt now contains common commands group in
the header [common]. sed ignore all lines in command-list.txt
until the [commands] list to correctly checks for missing
documentation on Git commands.
For the target common-cmds.h part:
Signed-off-by: Eric Sunshine <redacted>
I'm not convinced that it's a good idea to drop comment-line
processing from this sed invocation. Even though the current
command-list.txt may not have any comments following the [commands]
header, there is no guarantee that someone won't some day add some
comments following the header.
sed accepts multiple -e arguments, so retaining comment-line
processing does not make the extraction any more expensive. For
instance:
sed -e '1,/^\[commands\]/d' -e '/^#/d' <command-list.txt | \
quoted hunk
grep -q "^$$v[ ]" || \
case "$$v" in \
git) ;; \
@@ -2455,7 +2455,7 @@ check-docs:: esac ; \ done; \ ( \- sed -e '/^#/d' \+ sed -e '1,/^\[commands\]/d' \
Ditto. It would be more robust to retain comment-line processing.
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:43
On Sat, May 9, 2015 at 1:17 PM, Sébastien Guimmara
[off-list ref] wrote:
In the 6. step, add information about the common group commands
found in command-list.txt.
I don't feel too strongly about it, but as this is such a minor
change, and as it is directly related to the addition of the [common]
second in command-list.txt, it also would make sense just to fold this
change into the patch which introduces [common] (that is, v5 patch
3/6).
@@ -95,7 +95,9 @@ your language, document it in the INSTALL file. that categorizes commands by type, so they can be listed in appropriate subsections in the documentation's summary command list. Add an entry for yours. To understand the categories, look at git-commands.txt-in the main directory.+in the main directory. If the new command is part of the typical Git+workflow and you believe it's common enough to be mentioned in+'git help', map this command to a common group in the column [common] 7. Give the maintainer one paragraph to include in the RelNotes file to describe the new feature; a good place to do so is in the cover--
From: Eric Sunshine <hidden> Date: 2016-06-15 23:04:43
On Sat, May 9, 2015 at 1:17 PM, Sébastien Guimmara
[off-list ref] wrote:
quoted hunk
command-list.txt contains a [common] block that should be ignored
by the Documentation checker cmd-list.perl.
Filter out this block before the actual processing of the command list.
Signed-off-by: Sébastien Guimmara <redacted>
---
Why collect the lines into @filtered when you could instead merely
skip the unwanted ones outright?
while (<>) {
last if /^\[commands\]/;
}
And, then you don't need to touch the following 'for' loop at all.
my %cmds = ();
-for (sort <>) {
+for (sort @filtered) {
next if /^#/;
chomp;
--
2.4.0