Git相当于subversion的$ URL $关键字扩展 [英] Git equivalent of subversion's $URL$ keyword expansion

问题描述

我正在考虑从颠覆转移到git。我们使用Subversion为我们的系统管理员管理配置文件之类的东西之一。为此，我们将 $ URL $ 放入每个文件中，该文件扩展到文件在Subversion树中的位置。这可以让管理员查看某个任意主机上的文件，并找出它来自哪棵树的哪个位置。

我能找到的最接近的模拟是gitattributes。有 filter = 指令，但似乎git没有向过滤器传递它正在过滤的文件名，这将需要将 $ URL $ 放入路径中。

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

有什么建议吗？

工作流程如下：

1. 管理员提交对VCS回购的更改


2. 管理员更新已检出回购的中央库位
   
3. Admin使用cfengine将更改发送给主机 正如是否git有像 svn propset svn：关键字或前/后提交的钩子？，Git不支持关键字扩展
   
   
   

   使用git-sv处理SVN关键字扩展提供了一个基于 git config filter （这不正是你想要的）和/或 gitattributes 。

   
   
   

   ---

   
   
   

   文件信息扩展最接近的例子我发现它仍然基于涂抹/清洁方法，使用此git Hash过滤器 ，但干净的部分将其从文件中删除，并且找不到路径。

   
   
   

   这个线程实际上是拼写出来的（以及提及一些git-fu命令，这些命令可能包含你正在寻找的东西，我没有测试过它们）：
   
   

   
   

   无论如何，由于较小的技术缺陷，smudge / clean并不能立即解决问题：
   
   

   
   
   • 过滤器未传递正在检出的文件名称，因此无法准确找到提交标识符。
     
     但是，这可以通过事实上，'smudge'只是针对已更改的文件运行，所以最后一次提交是需要的。
   
   

   • 涂抹过滤器未传递提交标识符。这是一个更严重的问题，因为这些信息无处可逃。
     
     我尝试使用'HEAD'值，但显然它还没有在'smudge'正在运行的时候更新，所以这些文件最终会以上一个提交的日期而不是提交被签出。
     
     上一个表示之前签出的提交。如果不同的分支结帐，问题会变得更糟，因为这些文件会得到前一分支的时间戳。

   AFAIR ，污迹过滤器中缺乏信息是故意的，以阻止这种特别使用污迹/清洁机制。但是，考虑到Peter的使用案例，我认为可以重新考虑这一点：checkout-only工作区用于立即发布到web服务器。
   
   此外，任何对此用例感兴趣的人都可以实施其他涂抹参数，本地修补程序。
   
   

   然后，有一些小的烦恼，这似乎是不可避免的：如果您更改'干净'过滤器并检出较早版本，它将被报告为有修改（由于改变了'干净'定义）。
   

   
   

   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.

   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.

   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.

   Any suggestions?

   The workflow is as follows:

   1. Admin commits changes to the VCS repo
   2. Admin updates a central location that has checked out the repo
   3. Admin pulls the changes to the host using cfengine

   解决方案

   As mentioned in "Does git have anything like svn propset svn:keywords or pre-/post-commit hooks?", Git does not support keyword expansion.

   "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.

   ---

   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.

   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 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).

   这篇关于Git相当于subversion的$ URL $关键字扩展的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！