Ori Avtalion <ori@xxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html