别名扩展失败；不是git命令 [英] Expansion of alias failed; not a git command
问题描述
我肯定缺少明显的东西...但是Git别名根本无法正常工作.请帮帮我！
I must be missing something obvious... but Git aliases are not working at all. Help me please!
$ git config --global alias.v version
$ git config --global --list
alias.v=version
$ git config --global alias.v
version
$ git v
Expansion of alias 'v' failed; 'version' is not a git command
$ git version
git version 2.9.0
$ cat ~/.gitconfig
[alias]
v = version
更新1
按照@torek的建议，我用 log 测试了同样的东西，但它也不起作用:
Update 1
As per @torek's suggestion, I tested the same thing with log, and it also doesn't work:
$ git config --global alias.l log
$ git config --global --list
alias.v=version
alias.l=log
$ git config --global alias.l
log
$ git l
Expansion of alias 'l' failed; 'log' is not a git command
$ cat ~/.gitconfig
[alias]
v = version
l = log
更新2:已解决
问题是 git --exec-path 被设置为不正确的目录.最后，我从源代码构建和安装，现在一切正常.感谢所有提供帮助的人.
Update 2: Solved
The problem was that git --exec-path was somehow set to an incorrect directory. In the end, I built and installed from source and now everything works as expected. Thanks to everyone who helped.
推荐答案
使用 version 以外的命令.例如，尝试将 l 别名为 log .(或者，正如VonC所指出的那样，升级-它实际上在现代Git中确实起作用.在2.17.3和2.18.0之间似乎已经重写了别名处理.)
Use a command other than version. Try aliasing l to log, for instance. (Or, as VonC notes, upgrade—it actually does work in modern Git. The alias handling seems to have been rewritten between 2.17.3 and 2.18.0.)
这有点棘手！
大多数Git命令是-并且有时所有 Git命令 -将单独安装在目录(或文件夹，如果您更喜欢该术语)中的程序分开)，其中包含您可以运行的Git命令".例如， git log 实际上是由拼写为 git-log 的命令实现的，该命令安装在特殊的目录/文件夹中.
Most Git commands are—and at one point, all Git commands were—separate programs that are installed separately into a directory (or folder, if you prefer the term) full of "Git commands you can run". For instance, git log is actually implemented by a command spelled git-log, which is installed in a special directory / folder.
不过，此目录/文件夹不是 ，通常您是从运行运行命令的.
This directory / folder is not one you normally run commands from, though.
在遥远的过去，这些Git命令- git-log ， git-commit ， git-add ， git-diff 等-直接安装，然后通过键入 git- something 直接运行它们.这可以与bash的自动完成功能配合使用，因为您可以输入 git-com TAB 来获取提交命令，或者输入 git-ch TAB 以获取checkout命令.但是随着时间的流逝，Git命令的数量不断增加( git-cherry 和 git-cherry-pick )，并且越来越多；甚至根本没有输入足够的命令 git-add ，因为例如还存在 git-add--interactive ，所以 TAB 完成基本上完全停止了工作.
Back in the distant past, these Git commands—git-log, git-commit, git-add, git-diff, and so on—were all installed directly, and you ran them directly, by typing in git-something. This worked OK with bash's autocompletion, in that you could type git-comTAB to get the commit command, or git-chTAB to get the checkout command. But over time, the number of Git commands grew (git-cherry and git-cherry-pick), and grew, and grew; and eventually even typing in the full command git-add wasn't enough because there's also git-add--interactive for instance, so the TAB completion basically completely stopped working.
做出了一个决定:Git不会停止使用57个不同的命令-实际上，现在已经超过了150个-但相反，所有这些 implementation 命令都将被塞入一个地方他们不会一直都在你的脸上露面.拼写为 git 的单个前端命令将使您以 argument 的形式在前端 git 命令: git com ，然后是 TAB :bash现在具有 list 的 allowed 补全，并且将只选择 commit ，因为这是您您会使用的唯一 com ，而不是 git-commit-tree 或<仅脚本定期使用的code> git-commit-graph 后端程序.
A decision was made: Git wasn't going to stop coming with 57 different commands—actually, it's over 150 now—but instead, all these various implementation commands would be stuffed away into a place where they would not be all up in your face all the time. A single front end command, spelled git, would let you type in the command as an argument to the front-end git command: git com, then TAB: bash now has a list of allowed completions, and will only pick commit since that's the only com that you would use, not the git-commit-tree or git-commit-graph back end programs that only scripts regularly use.
因此:前端 git 命令知道如何查找和运行所有各种后端实现.按照惯例，它们大多数位于 git-core 目录中:run
So: the front end git command knows how to find and run all the various back end implementations. By convention, most of them are in the git-core directory: run
git --exec-path
，前端打印出所有后端程序实际居住的地方的名称.(您可以查看那里，甚至可以根据需要直接从那里运行它们，尽管现在，前端 git 命令现在可以设置后端命令可能需要的信息.)
and the front end prints out the name of the place where all the back-end programs actually live. (You can look in there, and even run them out of there directly if you like, although these days the front end git command now sets up information that the back end commands may want.)
但是 git版本呢?好了，既然您知道Git命令实际上位于 git-core 文件夹中，无论您的系统位于哪里，我建议您查看那里. git-version 程序在哪里?您将在其中找到 git-checkout ， git-log ， git-commit 和 git-diff 和许多其他代码，但您找不到 git-version .没有一个.
But what about git version? Well, now that you know that Git commands actually live in the git-core folder, wherever that may be on your system, I suggest you look in there. Where is the git-version program? You will find git-checkout in there, and git-log, and git-commit, and git-diff and many others, but you won't find a git-version. There isn't one.
version 命令直接内置在前端中.别名仅在调用后端命令时有效.因此，有-或曾经有-没有办法为 version 加上别名.(在某个时刻，显然是在2.9和2.24之前的版本中，别名处理代码也被精明了以检查前端内置组件.)
The version command is built directly in to the front end. The aliases only work when invoking a back end command. So there is—or was, anyway—no way to alias version. (At some point, obviously post 2.9 and pre 2.24, the alias handling code was smartened up to check the front-end built-ins as well.)
前端 git asdf 或 git rumplestiltskin 或 git helloworld (都不是实际的Git命令)时，它只是将内容设置为通常，然后尝试运行 git-asdf 或 git-rumplestiltskin 或 git-helloworld ，同时告诉系统在 git-core 目录中查找.它不会告诉系统 not 不能在 other 目录中查找.
The front end git command does know about some common back end commands, but it doesn't have a complete list of back end commands. Instead, when you type in git asdf or git rumplestiltskin or git helloworld—none of which are actual Git commands—it just sets things up as usual and then attempts to run git-asdf or git-rumplestiltskin or git-helloworld, while telling the system to look in the git-core directory. It doesn't tell the system not to look in other directories.
这意味着您可以编写您自己的 Git命令.如果需要 git asdf ，则可以编写自己的 git-asdf 程序，并将其放在任何位置，以便成功运行 git-asdf .现在，您可以使用 git asdf 来运行它.
This means you can write your own Git commands. If you want a git asdf, you can write your own git-asdf program, and put it anywhere so that running git-asdf succeeds. You can now run it using git asdf.
为什么，您可能会想，您会想要这样做吗?如果在自己的个人bin或脚本文件夹中安装 git-asdf ，则只需运行 git-asdf .确实，您可以做到这一点.但是，当您运行前端时，将使用提供的特殊Git设置信息来运行.这使您能够以sh(或bash)脚本 编写程序，并直接访问各种Git帮助器.主要帮助程序称为 git-sh-setup ，您可以通过使用.(POSIX)或 source (bash)采购"它来调用它):
Why, you might wonder, would you want to do this? If you install git-asdf in your own personal bin or scripts folder, you can just run git-asdf. And indeed, you can do that. But when you have the front end run it, you're run with special Git setup information provided. This gives you the ability to write your program as an sh (or bash) script and get direct access to various Git helpers. The main helper is called git-sh-setup and you invoke it by "sourcing" it, with . (POSIX) or source (bash):
#! /bin/sh
. git-sh-setup
这将添加shell函数 die 和 say 和 git_pager 和 require_clean_work_tree 等.如果在获取 git-sh-setup 之前设置了shell变量 OPTIONS_SPEC ，它将为您解析参数.查看脚本-它位于 git-core 目录中，以了解如何使用它.
This adds shell functions die and say and git_pager and require_clean_work_tree and more. If you set the shell variable OPTIONS_SPEC before sourcing git-sh-setup, it will parse arguments for you. Look at the script—it's right there in the git-core directory—to see how to use it.
(请注意，就像所有Git一样，它随着时间的推移而增长.例如，它现在的功能比Git 1.7时代要多.如果您想将某些东西移植到旧版Git，请克隆它.用于Git的Git存储库，选择一个兼容级别，然后对旧版本进行 git checkout 来查看您可以依靠的内容.)
(Note that, like all things Git, it has grown over time. It has more functions now than it did in the days of Git 1.7, for instance. If you want something that backports to older versions of Git, clone the Git repository for Git, pick a compatibility level, and git checkout the old one to see what you can rely on.)
这篇关于别名扩展失败；不是git命令的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
