Git相当于subversion的$URL$关键字扩展

Question

我正在考虑从 Subversion 迁移到 git。我们为系统管理员使用 subversion 来管理诸如配置文件之类的事情之一。为此，我们将 $URL$ 放入每个文件中，它会扩展到文件在 Subversion 树中的位置。这让管理员可以查看某个任意主机上的文件，并找出它在树中的位置。

我能找到的最接近的类比是 gitattributes。有 filter= 指令，但似乎 git 没有向过滤器传达它正在过滤的文件名，这对于将 $URL$ 转换为路径是必要的.

还有 ident 指令，它将把 $Id$ 变成 blob 散列。如果可以将其映射回路径名，这可能是有用的，但我的 git-fu 不够强大。

有什么建议吗？

工作流程如下:

1. 管理员提交对 VCS 存储库的更改
2. 管理员更新了一个已 checkout repo 协议(protocol)的中心位置
3. 管理员使用 cfengine 将更改提取到主机

Answer 1

如 "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 命令，我没有测试它们):

Anyway, smudge/clean does not give the immediate solution to the problem because of smaller technical shortcomings:

• smudge filter is not passed a name of file being checked out, so it is not possible to exactly find the commit identifier.
  However, this is alleviated by the fact that 'smudge' is only being run for the changed files, so the last commit is the needed one.

• smudge filter is not passed a commit identifier. This is a bit more serious, as this information is nowhere to get from otherwise.
  I tried to use 'HEAD' value, but apparently it is not yet updated at the moment 'smudge' is being run, so the files end up with the date of the "previous" commit rather than the commit being checked out.
  "Previous" means the commit that was checked out before. The problem gets worse if different branch is checkout out, as the files get the timestamp of a previous branch.

AFAIR, lack of information in smudge filter was intentional, to discourage this particular use of smudge/clean mechanism. However, I think this can be reconsidered given the Peter's use case: "checkout-only" workspace for immediate publishing to webserver.
Alternatively, anyone interested in this use case could implement additional smudge arguments as a site-local patch.

And then, there are small annoyances, which seems to be inevitable: if you change 'clean' filter and check out earlier revision, it will be reported as having modifications (due to changed 'clean' definition).