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

Rud*_*dog 15 git keyword

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

我能找到的最接近的模拟是gitattributes.有filter=指令,但似乎git没有向过滤器传达它过滤的文件名,这是转换$URL$成路径所必需的.

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

有什么建议?

工作流程如下:

  1. 管理员提交对VCS存储库的更改
  2. 管理员更新已签出仓库的中央位置
  3. 管理员使用cfengine将更改提取到主机

Von*_*onC 6

正如"git有什么类似svn propset svn:keywords或提交前/后提交钩子?"中所提到的那样.,Git不支持关键字扩展.

" 使用git-sv处理SVN关键字扩展 "提供了一种基于git config filter(这不是您想要的)和/或gitattributes的解决方案.


最接近的例子,如果文件信息扩展我发现它仍然基于涂抹/清理方法,使用这个git哈希过滤器,但干净部分将其从文件中删除,并且找不到路径.

这个帖子实际上说明了它(以及提到一些可能包含你正在寻找的git-fu命令,我还没有测试过它们):

无论如何,由于技术缺陷较小,涂抹/清洁无法立即解决问题:

  • smudge过滤器未传递正在检出的文件的名称,因此无法准确找到提交标识符.
    但是,通过仅为更改的文件运行'smudge'这一事实可以缓解这种情况,因此最后一次提交必需的.

  • smudge过滤器未传递提交标识符.这有点严重,因为这些信息无处可去.
    我试图使用'HEAD'值,但显然它现在还没有更新'smudge'正在运行,所以文件最后是"上一次"提交的日期,而不是检出的提交.
    "上一个"表示之前签出的提交.如果检出不同的分支,则问题会变得更糟,因为文件会获得前一个分支的时间戳.

AFAIR,涂抹过滤器中缺乏信息是故意的,以阻止这种涂抹/清洁机制的特殊用途.但是,我认为这可以通过Peter的用例重新考虑:"仅限结账"工作区,可立即发布到网络服务器.
或者,对此用例感兴趣的任何人都可以将其他涂抹参数实现为站点本地补丁.

然后,有一些小烦恼,这似乎是不可避免的:如果你改变'干净'过滤器并检查早期版本,它将被报告为有修改(由于改变'干净'定义).