我正在考虑从subversion迁移到git。我们使用subversion为我们的系统管理员管理诸如配置文件之类的东西之一。为此，我们将$URL$放入每个文件中，该文件扩展到subversion树中文件的位置。这使管理员可以查看某个任意主机上的文件，并找出它来自树的位置。
我能找到的最接近的模拟是gitattributes。有filter=指令，但似乎git不会向过滤器传达它要过滤的文件名，这对于将$URL$转换为路径是必要的。
还有ident指令，它会将$Id$转换为blob哈希。如果可以将其映射回路径名，这可能是有用的，但我的git-fu不够强大。
有什么建议吗？
工作流程如下：
答案 0 :(得分：6)
如"Does git have anything like svn propset svn:keywords or pre-/post-commit hooks?"中所述，Git不支持关键字扩展。
“Dealing with SVN keyword expansion with git-sv”提供基于git config filter（不完全符合您的要求）和/或gitattributes的解决方案。
最接近的示例，如果文件信息扩展我发现它仍然基于涂抹/清理方法with this git Hash filter，但干净部分将其从文件中删除，并且找不到路径。
This thread实际上说明了它（以及提到一些可能包含你要找的东西的git-fu命令，我还没有测试过它们）：
无论如何，由于技术缺陷较小，涂抹/清洁无法立即解决问题：
smudge过滤器未传递正在检出的文件名，因此无法准确找到提交标识符。
但是，只有为更改的文件运行'smudge'这一事实才能缓解这种情况，因此最后一次提交是所需的文件。涂抹过滤器未传递提交标识符。这有点严重，因为这些信息无处可去 我试图使用'HEAD'值，但显然它现在还没有更新'smudge'正在运行，所以文件最后是“上一次”提交的日期，而不是签出的提交。 /> “上一个”表示之前签出的提交。如果签出不同的分支，问题会变得更糟，因为文件会获得前一个分支的时间戳。
AFAIR，涂抹过滤器中缺乏信息是故意的，以阻止这种涂抹/清洁机制的特殊用途。但是，我认为可以根据Peter的用例重新考虑这个问题：“仅限结帐”工作区，可立即发布到网络服务器。
或者，任何对此用例感兴趣的人都可以将其他涂抹参数实现为站点本地补丁。然后，有一些小烦恼，这似乎是不可避免的：如果你改变'干净'过滤器并检查早期版本，它将被报告为有修改（由于改变'干净'定义）。
答案 1 :(得分：4)
由于现在有%f选项，像git-rcs-keywords这样的脚本可以完成任务。
this answer已经提到过。
Sequence "%f" on the filter command line is replaced with
the name of the file the filter is working on. A filter
might use this in keyword substitution. For example:
[filter "p4"]
clean = git-p4-filter --clean %f
smudge = git-p4-filter --smudge %f
答案 2 :(得分：2)
从完全不同的角度来看问题，有问题的文件如何最终出现在终端主机上？我想今天它可以直接在那里检查，或者从另一台主机上已经检出的存储库中以某种方式复制？
如果是这样，您是否可以修改您的流程以便将文件签出到git存储库，并且脚本在结帐后执行$URL$或其他关键字扩展。这样你就可以做任何你喜欢的替换，并且只受限于已检出的存储库中的脚本所能解决的问题。
答案 3 :(得分：1)
我们在部署中使用“规范路径”解决方案（它们都是内部的，FWIW）。
所有软件都进入，例如 /d/sw/xyz/a.c 或 D：\ SW \ xyz \ a.c
部署文件的所有网址都反映了的 HTTP：//host/d/sw/xyz/a.c
存储库文件的URL以“sw”开头，例如的 GIT中：//githost/gitrepo/xyz/a.c
我们在配置中编码这些规范路径（如果它需要更改），我们有脚本/ API动态生成/引用URL，以便在组件之间进行动态链接。