Git 相当于 subversion 的 $URL$ 关键字扩展 [英] Git equivalent of subversion's $URL$ keyword expansion
问题描述
我正在考虑从 subversion 迁移到 git.我们为系统管理员使用 subversion 来管理配置文件之类的内容之一.为此，我们将 $URL$ 放入每个文件中，这会扩展到文件在 subversion 树中的位置.这让管理员可以查看某个任意主机上的文件，并找出它来自树中的哪个位置.
I am considering migrating from subversion to git. One of the things we use subversion for our sysadmins to manage things like configuration files. To that end, we put $URL$ into each file, which expands to the file's location in the subversion tree. This lets the admins look at a file on some arbitrary host and figure out where in the tree it came from.
我能找到的最接近的模拟是 gitattributes.有 filter= 指令，但似乎 git 没有向过滤器传达它正在过滤的文件名，这对于将 $URL$ 转换为路径是必要的.
The closest analog I could find is gitattributes. There is the filter= directive, but it seems that git doesn't communicate to the filter what filename it's filtering, which would be necessary to turn $URL$ into a path.
还有 ident 指令，它会将 $Id$ 转换为 blob 哈希.如果可以将其映射回路径名，这可能有用，但是我的 git-fu 不够强大.
There is also the ident directive, which would turn $Id$ into the blob hash. This might be usable if one could map that back into a pathname, but my git-fu isn't strong enough.
有什么建议吗?
工作流程如下:
- 管理员提交对 VCS 存储库的更改
- 管理员更新已检出存储库的中心位置
- 管理员使用 cfengine 将更改拉取到主机
推荐答案
如 git 有没有像 svn propset svn:keywords 或 pre-/post-commit hooks 之类的东西?"，Git 没有支持关键字扩展.
As mentioned in "Does git have anything like svn propset svn:keywords or pre-/post-commit hooks?", Git does not support keyword expansion.
"使用git-sv处理SVN关键字扩展" 提供了一个基于 git config filter(这不是你想要的)和/或 gitattributes.
"Dealing with SVN keyword expansion with git-sv" provides a solution based on git config filter (which is not exactly what you want) and/or gitattributes.
最接近的文件信息扩展示例我发现它仍然基于涂抹/清理方法，用这个git Hash过滤器，但是clean部分把它从文件中删除了，找不到路径.
The closest example if file information expansion I have found it still based on the smudge/clean approach, with this git Hash filter, but the clean part removes it from the file, and no path can be found.
这个帖子 实际上已经说明了(并提到了一些可能包含的 git-fu 命令)你在找什么，我没有测试过):
This thread actually spells it out (as well as mentioning some git-fu commands which might contain what you are looking for, I have not tested them):
无论如何，由于较小的技术缺陷，污迹/清洁并不能立即解决问题:
Anyway, smudge/clean does not give the immediate solution to the problem because of smaller technical shortcomings:
污点过滤器不会传递被检出文件的名称，因此不可能准确地找到提交标识符.
但是，由于'smudge' 仅针对已更改的文件运行，因此最后一次提交 是需要的.
污点过滤器未传递提交标识符.这有点严重，因为否则无法获得此信息.
我尝试使用 'HEAD' 值，但显然在运行 'smudge' 时它尚未更新，因此文件以上一个"提交的日期结束，而不是被检出的提交.
上一个"表示之前签出的提交.如果签出不同的分支，问题会变得更糟，因为文件获得了前一个分支的时间戳.
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，涂抹过滤器中缺少信息是有意的，以阻止这种特殊使用涂抹/清洁机制.但是，我认为考虑到 Peter 的用例，可以重新考虑这一点:仅结帐"工作区可立即发布到网络服务器.
或者，任何对此用例感兴趣的人都可以将其他涂抹参数实现为站点本地补丁.
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).
这篇关于Git 相当于 subversion 的 $URL$ 关键字扩展的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
