Hi,
Sebastian Schuberth wrote:
[...]
--- a/Documentation/technical/api-builtin.txt
+++ b/Documentation/technical/api-builtin.txt
@@ -14,7 +14,7 @@ Git:
. Add the external declaration for the function to `builtin.h`.
-. Add the command to `commands[]` table in `handle_internal_command()`,
+. Add the command to `commands[]` table in `handle_builtin()`,
Makes sense. Using consistent jargon makes for easier reading.
[...]
+++ b/git.c
[...]
@@ -563,14 +563,14 @@ int main(int argc, char **av)
[...]
if (starts_with(cmd, git-)) {
cmd += 4;
argv[0] = cmd;
- handle_internal_command(argc, argv);
+ handle_builtin(argc, argv);
- die(cannot handle %s internally, cmd);
+ die(cannot handle %s as a builtin, cmd);
I think this makes the user-visible message less clear.
Before when the user had a stale git-whatever link lingering in
gitexecdir, git would say
fatal: cannot handle whatever internally
which tells me git was asked to handle the whatever command internally
and was unable to. Afterward, it becomes
fatal: cannot handle whatever as a builtin
which requires that I learn the jargon use of builtin as a noun.
busybox's analogous message is applet not found. It's less likely
to come up when using git because it requires having a stray link to
git. A message like
$ git whatever
fatal: whatever: no such built-in command
would just leave me wondering I never claimed it was built-in; what's
going on? I think it would be simplest to keep it as
$ git whatever
fatal: cannot handle whatever internally
which at least makes it clear that this is a low-level error.
The rest of the patch looks good.
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
