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

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

[Ori Avtalion]

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(-)

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

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

[Junio C Hamano]

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.

> @@ -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.

>  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.

> 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.

> -'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.

> @@ -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.

> 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.

> @@ -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.

> 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.

>  `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.

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

[Erik Faye-Lund]

On Fri, Aug 7, 2009 at 8:15 PM, Junio C Hamano<gitster@pobox.com> wrote:
>> -'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

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

[Ori Avtalion]

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.
>

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" ?

>> -'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.

>
>>   --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

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

[Junio C Hamano]

Ori Avtalion <ori@avtalion.name> writes:

> 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".

>    "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".

> 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.

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

[Nanako Shiraishi]

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(-)

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/

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

[Ori Avtalion]

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!

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:

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
  --------

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

[Nanako Shiraishi]

Quoting Ori Avtalion <ori@avtalion.name>

> 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.

> 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/

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

[Ori Avtalion]

On 08/12/2009 01:59 AM, Nanako Shiraishi wrote:
>> -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"

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

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

>  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.

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

[Ori Avtalion]

On 08/12/2009 02:29 AM, Ori Avtalion wrote:
>>> -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?