threads / patch / 20452

patchChange mentions of "git programs" to "git commands"

Subject: [PATCH] Change mentions of "git programs" to "git commands"

## tl;dr

11 messages between Aug 7, 2009 and Aug 13, 2009. Diffs are folded; open one to read it.

replies: 10people: 4as markdown or json

Ori Avtalion· Aug 7, 2009, 14:24 UTC · lore

Most of the docs and printouts refer to "commands". This patch changes the other terminology to be consistent.

Signed-off-by: Ori Avtalion <ori@avtalion.name>
---
 Documentation/config.txt           |    4 ++--
 Documentation/fetch-options.txt    |    2 +-
 Documentation/git-rev-list.txt     |    2 +-
 Documentation/git.txt              |    4 ++--
 Documentation/gitattributes.txt    |    2 +-
 Documentation/gitcore-tutorial.txt |    4 ++--
 Documentation/user-manual.txt      |    2 +-
 help.c                             |    2 +-
 8 files changed, 11 insertions(+), 11 deletions(-)
Show changes to 8 files +11 −11

Documentation/config.txt, Documentation/fetch-options.txt, Documentation/git-rev-list.txt, Documentation/git.txt, Documentation/gitattributes.txt, Documentation/gitcore-tutorial.txt, Documentation/user-manual.txt, help.c

diff --git a/Documentation/config.txt b/Documentation/config.txt
index c6f09f8..e94a8ab 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -605,7 +605,7 @@ color.interactive.<slot>::
 	Use customized color for 'git-add --interactive'
 	output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
 	four distinct types of normal output from interactive
-	programs.  The values of these variables may be specified as
+	commands.  The values of these variables may be specified as
 	in color.branch.<slot>.
 
 color.pager::
@@ -1113,7 +1113,7 @@ instaweb.port::
 	linkgit:git-instaweb[1].
 
 interactive.singlekey::
-	In interactive programs, allow the user to provide one-letter
+	In interactive commands, allow the user to provide one-letter
 	input with a single key (i.e., without hitting enter).
 	Currently this is used only by the `\--patch` mode of
 	linkgit:git-add[1].  Note that this setting is silently
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index d313795..20bf512 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,7 +1,7 @@
 -q::
 --quiet::
 	Pass --quiet to git-fetch-pack and silence any other internally
-	used programs.
+	used utilities.
 
 -v::
 --verbose::
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index bf98c84..21ccccd 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -90,7 +90,7 @@ between the two operands.  The following two commands are equivalent:
 	$ git rev-list A...B
 -----------------------------------------------------------------------
 
-'git-rev-list' is a very essential git program, since it
+'git-rev-list' is a very essential git command, since it
 provides the ability to build and traverse commit ancestry graphs. For
 this reason, it has a lot of different options that enables it to be
 used by commands as different as 'git-bisect' and
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 5fd5953..fe13e09 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -189,7 +189,7 @@ because `git --help ...` is converted internally into `git
 help ...`.
 
 --exec-path::
-	Path to wherever your core git programs are installed.
+	Path to wherever your core git commands are installed.
 	This can also be controlled by setting the GIT_EXEC_PATH
 	environment variable. If no path is given, 'git' will print
 	the current setting and then exit.
@@ -327,7 +327,7 @@ Synching repositories
 
 include::cmds-synchingrepositories.txt[]
 
-The following are helper programs used by the above; end users
+The following are helper commands used by the above; end users
 typically do not use them directly.
 
 include::cmds-synchelpers.txt[]
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index aaa073e..1195e83 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -404,7 +404,7 @@ Performing a three-way merge
 
 The attribute `merge` affects how three versions of a file is
 merged when a file-level merge is necessary during `git merge`,
-and other programs such as `git revert` and `git cherry-pick`.
+and other commands such as `git revert` and `git cherry-pick`.
 
 Set::
 
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 7ba5e58..b3640c4 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -12,7 +12,7 @@ git *
 DESCRIPTION
 -----------
 
-This tutorial explains how to use the "core" git programs to set up and
+This tutorial explains how to use the "core" git commands to set up and
 work with a git repository.
 
 If you just need to use git as a revision control system you may prefer
@@ -1328,7 +1328,7 @@ into it later. Obviously, this repository creation needs to be
 done only once.
 
 [NOTE]
-'git-push' uses a pair of programs,
+'git-push' uses a pair of commands,
 'git-send-pack' on your local machine, and 'git-receive-pack'
 on the remote machine. The communication between the two over
 the network internally uses an SSH connection.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0b88a51..67ebffa 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4131,7 +4131,7 @@ What does this mean?
 
 `git rev-list` is the original version of the revision walker, which
 _always_ printed a list of revisions to stdout.  It is still functional,
-and needs to, since most new Git programs start out as scripts using
+and needs to, since most new Git commands start out as scripts using
 `git rev-list`.
 
 `git rev-parse` is not as important any more; it was only used to filter out
diff --git a/help.c b/help.c
index 6c46d8b..57a0e0e 100644
--- a/help.c
+++ b/help.c
@@ -334,7 +334,7 @@ const char *help_unknown_cmd(const char *cmd)
 		const char *assumed = main_cmds.names[0]->name;
 		main_cmds.names[0] = NULL;
 		clean_cmdnames(&main_cmds);
-		fprintf(stderr, "WARNING: You called a Git program named '%s', "
+		fprintf(stderr, "WARNING: You called a Git command named '%s', "
 			"which does not exist.\n"
 			"Continuing under the assumption that you meant '%s'\n",
 			cmd, assumed);
-- 
1.6.0.4
Junio C Hamano· Aug 7, 2009, 18:15 UTC · re: Ori Avtalion · lore

Re: [PATCH] Change mentions of "git programs" to "git commands"

Ori Avtalion <ori@avtalion.name> writes:
> Most of the docs and printouts refer to "commands".
> This patch changes the other terminology to be consistent.
Thanks, but not really.
Show 6 quoted lines
> @@ -605,7 +605,7 @@ color.interactive.<slot>::
>  	Use customized color for 'git-add --interactive'
>  	output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
>  	four distinct types of normal output from interactive
> -	programs.  The values of these variables may be specified as
> +	commands.  The values of these variables may be specified as
This is good.
Show 7 quoted lines
>  color.pager::
> @@ -1113,7 +1113,7 @@ instaweb.port::
>  	linkgit:git-instaweb[1].
>  
>  interactive.singlekey::
> -	In interactive programs, allow the user to provide one-letter
> +	In interactive commands, allow the user to provide one-letter
This is good.
Show 10 quoted lines
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index d313795..20bf512 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -1,7 +1,7 @@
>  -q::
>  --quiet::
>  	Pass --quiet to git-fetch-pack and silence any other internally
> -	used programs.
> +	used utilities.

This does not have much to do with what you claim to have done in the commit log message nor the title. Probably "utilities" is a slightly better word than "programs" in this context but not by a wide margin.

Show 5 quoted lines
> -'git-rev-list' is a very essential git program, since it
> +'git-rev-list' is a very essential git command, since it
>  provides the ability to build and traverse commit ancestry graphs. For
>  this reason, it has a lot of different options that enables it to be
>  used by commands as different as 'git-bisect' and
Ok, but probably we would want to say "git rev-list" here.
>  --exec-path::
> -	Path to wherever your core git programs are installed.
> +	Path to wherever your core git commands are installed.
I do not think this is a good change.

When you talk about git "command", e.g. "'git rev-list' is an essential command", you are talking about an abstract concept. In the reader's world view, there is one single toplevel program called "git" and it has various commands, one of which is 'rev-list'. But this description is not about an abstract concept of command, but is about a particular implementation detail. For every git command, there is a corresponding git _program_ that implements that command, and --exec-path tells you (or you use --exec-path to tell the git toplevel program) where they are.

You kept this intact in gitcore-tutorial:
    ... Also
    you need to make sure that you have the 'git-receive-pack'
    program on the `$PATH`.

and I think you did the right thing. This is about a concrete instance of a program. If you really really want to say _command_, you would probably want to do something like this instead:

 --exec-path::
-	Path to wherever your core git programs are installed.
+	Path to the directory that holds programs that implements git commands.
Show 7 quoted lines
> @@ -327,7 +327,7 @@ Synching repositories
>  
>  include::cmds-synchingrepositories.txt[]
>  
> -The following are helper programs used by the above; end users
> +The following are helper commands used by the above; end users
>  typically do not use them directly.
Ok.
>  The attribute `merge` affects how three versions of a file is
>  merged when a file-level merge is necessary during `git merge`,
> -and other programs such as `git revert` and `git cherry-pick`.
> +and other commands such as `git revert` and `git cherry-pick`.
Ok.
Show 13 quoted lines
> diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
> index 7ba5e58..b3640c4 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -12,7 +12,7 @@ git *
>  DESCRIPTION
>  -----------
>  
> -This tutorial explains how to use the "core" git programs to set up and
> +This tutorial explains how to use the "core" git commands to set up and
>  work with a git repository.
>  
>  If you just need to use git as a revision control system you may prefer
Ok.
Show 9 quoted lines
> @@ -1328,7 +1328,7 @@ into it later. Obviously, this repository creation needs to be
>  done only once.
>  
>  [NOTE]
> -'git-push' uses a pair of programs,
> +'git-push' uses a pair of commands,
>  'git-send-pack' on your local machine, and 'git-receive-pack'
>  on the remote machine. The communication between the two over
>  the network internally uses an SSH connection.
Ok.
Show 11 quoted lines
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 0b88a51..67ebffa 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -4131,7 +4131,7 @@ What does this mean?
>  
>  `git rev-list` is the original version of the revision walker, which
>  _always_ printed a list of revisions to stdout.  It is still functional,
> -and needs to, since most new Git programs start out as scripts using
> +and needs to, since most new Git commands start out as scripts using
>  `git rev-list`.
Ok.
Show 14 quoted lines
>  `git rev-parse` is not as important any more; it was only used to filter out
> diff --git a/help.c b/help.c
> index 6c46d8b..57a0e0e 100644
> --- a/help.c
> +++ b/help.c
> @@ -334,7 +334,7 @@ const char *help_unknown_cmd(const char *cmd)
>  		const char *assumed = main_cmds.names[0]->name;
>  		main_cmds.names[0] = NULL;
>  		clean_cmdnames(&main_cmds);
> -		fprintf(stderr, "WARNING: You called a Git program named '%s', "
> +		fprintf(stderr, "WARNING: You called a Git command named '%s', "
>  			"which does not exist.\n"
>  			"Continuing under the assumption that you meant '%s'\n",
>  			cmd, assumed);
Ok.
Erik Faye-Lund· Aug 8, 2009, 12:12 UTC · re: Junio C Hamano · lore

Re: [PATCH] Change mentions of "git programs" to "git commands"

On Fri, Aug 7, 2009 at 8:15 PM, Junio C Hamano<gitster@pobox.com> wrote:
Show 7 quoted lines
>> -'git-rev-list' is a very essential git program, since it
>> +'git-rev-list' is a very essential git command, since it
>>  provides the ability to build and traverse commit ancestry graphs. For
>>  this reason, it has a lot of different options that enables it to be
>>  used by commands as different as 'git-bisect' and
>
> Ok, but probably we would want to say "git rev-list" here.

...or maybe just "rev-list", as we're now talking about a git-command (and not how you invoke it)?

-- 
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
Ori Avtalion· Aug 8, 2009, 13:26 UTC · re: Junio C Hamano · lore

Re: [PATCH] Change mentions of "git programs" to "git commands"

On 08/07/2009 09:15 PM, Junio C Hamano wrote:
Show 22 quoted lines
> Ori Avtalion<ori@avtalion.name>  writes:
>
>> Most of the docs and printouts refer to "commands".
>> This patch changes the other terminology to be consistent.
>
> Thanks, but not really.
>
>> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
>> index d313795..20bf512 100644
>> --- a/Documentation/fetch-options.txt
>> +++ b/Documentation/fetch-options.txt
>> @@ -1,7 +1,7 @@
>>   -q::
>>   --quiet::
>>   	Pass --quiet to git-fetch-pack and silence any other internally
>> -	used programs.
>> +	used utilities.
>
> This does not have much to do with what you claim to have done in the
> commit log message nor the title.  Probably "utilities" is a slightly
> better word than "programs" in this context but not by a wide margin.
>
I picked the word from the glossary definition of "core git":
   "Fundamental data structures and utilities of git. [...]"
If that doesn't fit, how about:
    "Pass --quiet to git-fetch-pack and silence other output" ?
Show 7 quoted lines
>> -'git-rev-list' is a very essential git program, since it
>> +'git-rev-list' is a very essential git command, since it
>>   provides the ability to build and traverse commit ancestry graphs. For
>>   this reason, it has a lot of different options that enables it to be
>>   used by commands as different as 'git-bisect' and
>
> Ok, but probably we would want to say "git rev-list" here.

In that case, shouldn't all of the manpages be changed to say "git foo" instead of "git-foo" under the NAME section?

I see the "git-foo" notation as a convention for git commands. It may be for historical reasons, but the manpage for the "pull" git command is "git-pull", and that is how commands are mentioned all over the documentation.

Show 30 quoted lines
>
>>   --exec-path::
>> -	Path to wherever your core git programs are installed.
>> +	Path to wherever your core git commands are installed.
>
> I do not think this is a good change.
>
> When you talk about git "command", e.g. "'git rev-list' is an essential
> command", you are talking about an abstract concept.  In the reader's
> world view, there is one single toplevel program called "git" and it has
> various commands, one of which is 'rev-list'.  But this description is not
> about an abstract concept of command, but is about a particular
> implementation detail.  For every git command, there is a corresponding
> git _program_ that implements that command, and --exec-path tells you (or
> you use --exec-path to tell the git toplevel program) where they are.
>
> You kept this intact in gitcore-tutorial:
>
>      ... Also
>      you need to make sure that you have the 'git-receive-pack'
>      program on the `$PATH`.
>
> and I think you did the right thing.  This is about a concrete instance of
> a program.  If you really really want to say _command_, you would probably
> want to do something like this instead:
>
>   --exec-path::
> -	Path to wherever your core git programs are installed.
> +	Path to the directory that holds programs that implements git commands.
>
I agree with the suggestion.
I found a few other instances that should probably be changed.
In git.txt:
"The following are helper programs used by the above"
                           ^^^^^^^^
                           commands
In git-mailsplit.txt (and cmds-purehelpers.txt):
    "Simple UNIX mbox splitter program."
Maybe the word "program" should just be dropped.
I'll submit a new patch once there's an agreement on the changes.
-Ori
Junio C Hamano· Aug 8, 2009, 16:12 UTC · re: Ori Avtalion · lore

Re: [PATCH] Change mentions of "git programs" to "git commands"

Ori Avtalion <ori@avtalion.name> writes:
Show 24 quoted lines
> On 08/07/2009 09:15 PM, Junio C Hamano wrote:
>> Ori Avtalion<ori@avtalion.name>  writes:
>>
>>> Most of the docs and printouts refer to "commands".
>>> This patch changes the other terminology to be consistent.
>>
>> Thanks, but not really.
>>
>>> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
>>> index d313795..20bf512 100644
>>> --- a/Documentation/fetch-options.txt
>>> +++ b/Documentation/fetch-options.txt
>>> @@ -1,7 +1,7 @@
>>>   -q::
>>>   --quiet::
>>>   	Pass --quiet to git-fetch-pack and silence any other internally
>>> -	used programs.
>>> +	used utilities.
>>
>> This does not have much to do with what you claim to have done in the
>> commit log message nor the title.  Probably "utilities" is a slightly
>> better word than "programs" in this context but not by a wide margin.
>
> If that doesn't fit,...

My comment on this part was not "Don't change this wording, the original is much better", but was primarily "you said this commit is about replacing 'program' with 'command' for consistency, but this change does not belong to that category. Either make a separate commit for this change separate from all the rest, or change the wording of the commit log message to cover this one as well".

Show 14 quoted lines
>    "Pass --quiet to git-fetch-pack and silence other output" ?
>
>>> -'git-rev-list' is a very essential git program, since it
>>> +'git-rev-list' is a very essential git command, since it
>>>   provides the ability to build and traverse commit ancestry graphs. For
>>>   this reason, it has a lot of different options that enables it to be
>>>   used by commands as different as 'git-bisect' and
>>
>> Ok, but probably we would want to say "git rev-list" here.
> ...
> I see the "git-foo" notation as a convention for git commands.
> It may be for historical reasons, but the manpage for the "pull" git
> command is "git-pull", and that is how commands are mentioned all over
> the documentation.

This was "because you are changing the exact sentence anyway, why not do this while you are at it". But you are probably right. We try to write "git foo" when we talk about what users would type, but say "git-foo" when we talk about the command itself. When we talk about the concept of what the command achieves, we sometimes say just "foo".

Show 9 quoted lines
> In git.txt:
> "The following are helper programs used by the above"
>                           ^^^^^^^^
>                           commands
>
> In git-mailsplit.txt (and cmds-purehelpers.txt):
>    "Simple UNIX mbox splitter program."
>
> Maybe the word "program" should just be dropped.

That may be an option and I kind of like it; but I'd rather hear from others first.

Nanako Shiraishi· Aug 11, 2009, 03:58 UTC · re: Ori Avtalion · lore
From: Ori Avtalion <ori@avtalion.name>
Date: Fri, 7 Aug 2009 17:24:21 +0300
Subject: [PATCH] Change mentions of "git programs" to "git commands"

Most of the docs and printouts refer to "commands" when discussing what the end users call via the "git" top-level program. We should refer them as "git programs" when we discuss the fact that the commands are implemented as separate programs, but in other contexts, it is better to use the term "git commands" consistently.

Signed-off-by: Ori Avtalion <ori@avtalion.name>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
 Junio, it appeard to me that you had some minor issues with Ori's patch but you knew exactly how they should be addressed and you thought it was a good change overall.
 I copy-edited Ori's patch for your convenience, and tried to clarify the criteria you used to decide which "program" should become "command" in the updated commit log message, in case you forgot to apply it yourself.
 I just didn't want to see the time you and others spent on submitting and reviewing wasted due to lack of resubmission of a revised patch.
 Documentation/config.txt           |    4 ++--
 Documentation/fetch-options.txt    |    2 +-
 Documentation/git-rev-list.txt     |    2 +-
 Documentation/git.txt              |    4 ++--
 Documentation/gitattributes.txt    |    2 +-
 Documentation/gitcore-tutorial.txt |    4 ++--
 Documentation/user-manual.txt      |    2 +-
 help.c                             |    2 +-
 8 files changed, 11 insertions(+), 11 deletions(-)
Show changes to 8 files +10 −10

Documentation/config.txt, Documentation/fetch-options.txt, Documentation/git-rev-list.txt, Documentation/git.txt, Documentation/gitattributes.txt, Documentation/gitcore-tutorial.txt, Documentation/user-manual.txt, help.c

diff --git a/Documentation/config.txt b/Documentation/config.txt
index c6f09f8..e94a8ab 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -605,7 +605,7 @@ color.interactive.<slot>::
 	Use customized color for 'git-add --interactive'
 	output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
 	four distinct types of normal output from interactive
-	programs.  The values of these variables may be specified as
+	commands.  The values of these variables may be specified as
 	in color.branch.<slot>.
 
 color.pager::
@@ -1113,7 +1113,7 @@ instaweb.port::
 	linkgit:git-instaweb[1].
 
 interactive.singlekey::
-	In interactive programs, allow the user to provide one-letter
+	In interactive commands, allow the user to provide one-letter
 	input with a single key (i.e., without hitting enter).
 	Currently this is used only by the `\--patch` mode of
 	linkgit:git-add[1].  Note that this setting is silently
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index d313795..20bf512 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,7 +1,7 @@
 -q::
 --quiet::
 	Pass --quiet to git-fetch-pack and silence any other internally
-	used programs.
+	used git commands.
 
 -v::
 --verbose::
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index bf98c84..21ccccd 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -90,7 +90,7 @@ between the two operands.  The following two commands are equivalent:
 	$ git rev-list A...B
 -----------------------------------------------------------------------
 
-'git-rev-list' is a very essential git program, since it
+'rev-list' is a very essential git command, since it
 provides the ability to build and traverse commit ancestry graphs. For
 this reason, it has a lot of different options that enables it to be
 used by commands as different as 'git-bisect' and
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 5fd5953..fe13e09 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -327,7 +327,7 @@ Synching repositories
 
 include::cmds-synchingrepositories.txt[]
 
-The following are helper programs used by the above; end users
+The following are helper commands used by the above; end users
 typically do not use them directly.
 
 include::cmds-synchelpers.txt[]
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index aaa073e..1195e83 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -404,7 +404,7 @@ Performing a three-way merge
 
 The attribute `merge` affects how three versions of a file is
 merged when a file-level merge is necessary during `git merge`,
-and other programs such as `git revert` and `git cherry-pick`.
+and other commands such as `git revert` and `git cherry-pick`.
 
 Set::
 
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 7ba5e58..b3640c4 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -12,7 +12,7 @@ git *
 DESCRIPTION
 -----------
 
-This tutorial explains how to use the "core" git programs to set up and
+This tutorial explains how to use the "core" git commands to set up and
 work with a git repository.
 
 If you just need to use git as a revision control system you may prefer
@@ -1328,7 +1328,7 @@ into it later. Obviously, this repository creation needs to be
 done only once.
 
 [NOTE]
-'git-push' uses a pair of programs,
+'git-push' uses a pair of commands,
 'git-send-pack' on your local machine, and 'git-receive-pack'
 on the remote machine. The communication between the two over
 the network internally uses an SSH connection.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0b88a51..67ebffa 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4131,7 +4131,7 @@ What does this mean?
 
 `git rev-list` is the original version of the revision walker, which
 _always_ printed a list of revisions to stdout.  It is still functional,
-and needs to, since most new Git programs start out as scripts using
+and needs to, since most new Git commands start out as scripts using
 `git rev-list`.
 
 `git rev-parse` is not as important any more; it was only used to filter out
diff --git a/help.c b/help.c
index 6c46d8b..57a0e0e 100644
--- a/help.c
+++ b/help.c
@@ -334,7 +334,7 @@ const char *help_unknown_cmd(const char *cmd)
 		const char *assumed = main_cmds.names[0]->name;
 		main_cmds.names[0] = NULL;
 		clean_cmdnames(&main_cmds);
-		fprintf(stderr, "WARNING: You called a Git program named '%s', "
+		fprintf(stderr, "WARNING: You called a Git command named '%s', "
 			"which does not exist.\n"
 			"Continuing under the assumption that you meant '%s'\n",
 			cmd, assumed);
-- 
1.6.2.GIT

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
Ori Avtalion· Aug 11, 2009, 11:49 UTC · re: Nanako Shiraishi · lore

Re: [PATCH] Change mentions of "git programs" to "git commands"

On 08/11/2009 06:58 AM, Nanako Shiraishi wrote:
Show 14 quoted lines
> From: Ori Avtalion<ori@avtalion.name>
> Date: Fri, 7 Aug 2009 17:24:21 +0300
> Subject: [PATCH] Change mentions of "git programs" to "git commands"
>
> Most of the docs and printouts refer to "commands" when discussing what
> the end users call via the "git" top-level program. We should refer them
> as "git programs" when we discuss the fact that the commands are
> implemented as separate programs, but in other contexts, it is better to
> use the term "git commands" consistently.
>
> Signed-off-by: Ori Avtalion<ori@avtalion.name>
> Signed-off-by: Nanako Shiraishi<nanako3@lavabit.com>
> ---
>
Thanks Nanako!

I'm fine with the changes. (it doesn't help much to nitpick on 'git-foo' vs 'git foo' vs 'foo' :)

You might want to consider this patch too:
Show changes to Documentation/git-mailsplit.txt +1 −1
diff --git a/Documentation/git-mailsplit.txt 
b/Documentation/git-mailsplit.txt
index 5cc94ec..8f1b99b 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -3,7 +3,7 @@ git-mailsplit(1)

  NAME
  ----
-git-mailsplit - Simple UNIX mbox splitter program
+git-mailsplit - Simple UNIX mbox splitter

  SYNOPSIS
  --------
Nanako Shiraishi· Aug 11, 2009, 22:59 UTC · re: Ori Avtalion · lore

Re: [PATCH] Change mentions of "git programs" to "git commands"

Quoting Ori Avtalion <ori@avtalion.name>
Show 17 quoted lines
> On 08/11/2009 06:58 AM, Nanako Shiraishi wrote:
>> From: Ori Avtalion<ori@avtalion.name>
>> Date: Fri, 7 Aug 2009 17:24:21 +0300
>> Subject: [PATCH] Change mentions of "git programs" to "git commands"
>>
>> Most of the docs and printouts refer to "commands" when discussing what
>> the end users call via the "git" top-level program. We should refer them
>> as "git programs" when we discuss the fact that the commands are
>> implemented as separate programs, but in other contexts, it is better to
>> use the term "git commands" consistently.
>>
>> Signed-off-by: Ori Avtalion<ori@avtalion.name>
>> Signed-off-by: Nanako Shiraishi<nanako3@lavabit.com>
>> ---
>>
>
> Thanks Nanako!

You're welcome, and sorry if I sounded as if I was accusing that you were wasting other's time by not re-submitting sooner. I only wanted to see a good patch go in.

Show 16 quoted lines
> You might want to consider this patch too:
>
> diff --git a/Documentation/git-mailsplit.txt
> b/Documentation/git-mailsplit.txt
> index 5cc94ec..8f1b99b 100644
> --- a/Documentation/git-mailsplit.txt
> +++ b/Documentation/git-mailsplit.txt
> @@ -3,7 +3,7 @@ git-mailsplit(1)
>
>  NAME
>  ----
> -git-mailsplit - Simple UNIX mbox splitter program
> +git-mailsplit - Simple UNIX mbox splitter
>
>  SYNOPSIS
>  --------
Sorry, but I don't understand why it is necessary.
-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
Ori Avtalion· Aug 11, 2009, 23:29 UTC · re: Nanako Shiraishi · lore

Re: [PATCH] Change mentions of "git programs" to "git commands"

On 08/12/2009 01:59 AM, Nanako Shiraishi wrote:
Show 8 quoted lines
>> -git-mailsplit - Simple UNIX mbox splitter program
>> +git-mailsplit - Simple UNIX mbox splitter
>>
>>   SYNOPSIS
>>   --------
>
> Sorry, but I don't understand why it is necessary.
>

It's another case where a command is called a "program" when, to the user, it's simply a command such as "git mailsplit". Having the word "command" in a command description is redundant, so I just dropped the word.

And here's another command with a similar description that I missed before: "git-merge-one-file - The standard helper *program* to use with git-merge-index"

Ori Avtalion· Aug 13, 2009, 12:02 UTC · re: Ori Avtalion · lore

Re: [PATCH] Change mentions of "git programs" to "git commands"

On 08/12/2009 02:29 AM, Ori Avtalion wrote:
Show 15 quoted lines
>>> -git-mailsplit - Simple UNIX mbox splitter program
>>> +git-mailsplit - Simple UNIX mbox splitter
>>>
>>> SYNOPSIS
>>> --------
>>
>
> It's another case where a command is called a "program" when, to the
> user, it's simply a command such as "git mailsplit". Having the word
> "command" in a command description is redundant, so I just dropped the
> word.
>
> And here's another command with a similar description that I missed before:
> "git-merge-one-file - The standard helper *program* to use with
> git-merge-index"
Should I create a new patch for these two? Or is the change not welcome?
Junio C Hamano· Aug 12, 2009, 22:39 UTC · re: Nanako Shiraishi · lore

Re: [PATCH] Change mentions of "git programs" to "git commands"

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 7 quoted lines
>  I copy-edited Ori's patch for your convenience, and tried to clarify
>  the criteria you used to decide which "program" should become "command"
>  in the updated commit log message, in case you forgot to apply it
>  yourself.
>
>  I just didn't want to see the time you and others spent on submitting
>  and reviewing wasted due to lack of resubmission of a revised patch.

Very thoughtful. I appreciate your occasional "playing a capable project secretary", and I wish I see more like you.

Indeed I've been swamped, and I tend to leave the final wrapping up to the original submitter and then forget.

Thanks.

← back to recent threads