从 CVS 迁移到 Git：$Id$ 等效吗？

Question

我读了一堆关于简单源代码控制工具的问题，Git 似乎是一个合理的选择。 我已经启动并运行了它，到目前为止效果很好。 我喜欢 CVS 的一方面是版本号的自动递增。

我知道这在分布式存储库中没有多大意义，但作为开发人员，我想要/需要这样的东西。 让我解释一下原因：

我使用 Emacs。 我会定期检查并寻找第三方软件包的 Lisp 源文件的新版本。 假设我有一个文件 foo.el，根据标头，该文件的版本是 1.3； 如果我查找最新版本并看到它是 1.143 或 2.6 或其他版本，我知道我已经落后很多了。

相反，如果我看到几个 40 个字符的哈希值，我将不知道哪个晚了，也不知道晚了多少。 如果我必须手动检查 ChangeLogs 只是为了了解我有多过时，我绝对会讨厌它。

作为一名开发人员，我想将这种礼貌延伸到使用我的输出的人（也许我在自欺欺人地认为任何人都是如此，但让我们暂时将其放在一边）。 我不想每次都必须记住自己增加该死的数字，或者时间戳或类似的东西。 这是真正的 PITA，我从经验中知道这一点。

那么我还有什么选择呢？ 如果我无法获得 $Id:$ 等价物，我还能如何提供我正在寻找的东西？

我应该提到的是，我的期望是最终用户不会安装 Git，即使安装了，也不会拥有本地存储库（事实上，我希望不要以这种方式提供它）。

Answer 1

SHA 只是版本的一种表示（尽管是规范的）。 git describe 命令提供了其他命令，并且做得非常好。

例如，当我在 Java memcached 的 master 分支中运行 gitdescribe 时client 源，我明白了：

2.2-16-gc0cd61a

这说明了两件重要的事情：

1. 自 2.2 以来，此树中已经有 16 次提交
2. 确切 源树可以显示在其他任何人的克隆上。

举例来说，您将一个 version 文件与源代码一起打包（甚至重写了所有内容以进行分发）以显示该数字。 假设打包版本是 2.2-12-g6c4ae7a（不是发行版，而是有效版本）。

您现在可以准确地看到您落后了多远（4 次提交）， 您可以准确地看到哪 4 次提交：

# The RHS of the .. can be origin/master or empty, or whatever you want.
% git log --pretty=format:"%h %an %s" 2.2-12-g6c4ae7a..2.2-16-gc0cd61a
c0cd61a Dustin Sallings More tries to get a timeout.
8c489ff Dustin Sallings Made the timeout test run on every protocol on every bui
fb326d5 Dustin Sallings Added a test for bug 35.
fba04e9 Valeri Felberg Support passing an expiration date into CAS operations.

Answer 2

现在 Git 中已经支持 $Id:$ 了。 要为文件 README 启用它，您可以将“README ident”放入 .gitattributes 中。 支持文件名通配符。 有关详细信息，请参阅 man gitattributes。

Answer 3

这并不是OP的无理要求。

我的用例是：

1. 我将 Git 用于我自己的个人代码，因此不与其他人协作。
2. 我将系统 Bash 脚本保留在其中，准备好后可能会进入 /usr/local/bin 。

我使用三台独立的机器，上面有相同的 Git 存储库。 很高兴知道我当前在 /usr/local/bin 中的文件的“版本”，而无需手动执行“diff -u”。

对于那些持消极态度的人，请记住还有其他用例。 并非每个人都使用 Git 进行协作工作，Git 存储库中的文件是其“最终”位置。

不管怎样，我这样做的方法是在存储库中创建一个属性文件，如下所示：

cat .git/info/attributes
# see man gitattributes
*.sh ident
*.pl ident
*.cgi ident

然后将 $Id$ 放在文件中的某个位置（我喜欢将其放在 shebang 之后）。

提交。 请注意，这不会像我预期的那样自动进行扩展。 例如，您必须重新编译该文件，

git commit foo.sh
rm foo.sh
git co foo.sh

然后您将看到扩展，例如：

$ head foo.sh
#!/bin/sh

# $Id: e184834e6757aac77fd0f71344934b1cd774e6d4 $

如何为 Git 存储库启用 ident 字符串？。

Answer 4

不确定这是否会出现在 Git 中。 引用 Linus：

“关键字替换的整个概念完全是愚蠢的。它是
如果您愿意，在实际内容跟踪的“外部”进行微不足道的操作
在以焦油球等形式发布树时拥有它。”

不过，检查日志非常容易 - 如果您正在跟踪 foo.el 的稳定分支，您可以看到稳定分支日志中哪些新提交是不存在的如果你想模拟 CVS 的内部版本号，你可以比较最后一次提交的时间戳。

编辑：你应该为此编写或使用其他人的脚本，当然，不要手动执行此操作。

Answer 5

正如我之前所写：

使用像 Bazaar 这样的 DSCM 工具不可能自动生成显示合理版本号的 ID 标签，因为每个人的开发路线都可能与其他人不同。 因此，有人可以引用文件的版本“1.41”，但您的该文件的版本“1.41”是不同的。

基本上，$Id$ 对于 Bazaar、Git 和其他分布式源代码管理工具没有任何意义。

Answer 6

我有同样的问题。 我需要一个比哈希字符串更简单的版本，并且可供使用该工具的人使用，而无需连接到存储库。

我使用 Git 预提交挂钩来完成此操作，并更改了我的脚本以能够自动更新自身。

我根据完成的提交数量来确定版本。 这是一个轻微的竞争条件，因为两个人可以同时提交，并且都认为他们正在提交相同的版本号，但我们在这个项目上没有很多开发人员。

举个例子，我有一个用 Ruby 签入的脚本，我向其中添加了这段代码 - 这是非常简单的代码，因此如果您用不同的语言签入某些内容，很容易移植到不同的语言（尽管显然这无法轻松处理不可运行的签入（例如文本文件）。 我添加了：

MYVERSION = '1.090'
## Call script to do updateVersion from .git/hooks/pre-commit
def updateVersion
  # We add 1 because the next commit is probably one more - though this is a race
  commits = %x[git log #{$0} | grep '^commit ' | wc -l].to_i + 1
  vers = "1.%0.3d" % commits

  t = File.read($0)
  t.gsub!(/^MYVERSION = '(.*)'$/, "MYVERSION = '#{vers}'")
  bak = $0+'.bak'
  File.open(bak,'w') { |f| f.puts t }
  perm = File.stat($0).mode & 0xfff
  File.rename(bak,$0)
  File.chmod(perm,$0)
  exit
end

然后我向脚本添加了一个命令行选项（-updateVersion），因此如果我将其称为“工具-updateVersion”，那么它只会调用工具的 updateVersion 来修改“MYVERSION”值本身，并且然后退出（如果您愿意，您也可以让它更新其他打开的文件）。

设置完成后，我会转到 Git 头并在 .git/hooks/pre-commit 中创建一个可执行的单行 bash 脚本。

该脚本只是更改为 Git 目录的头部并使用 -updateVersion 调用我的脚本。

每次我签入时，都会运行预提交脚本，该脚本会使用 -updateVersion 运行我的脚本，然后根据提交次数更新 MYVERSION 变量。 魔法！

Answer 7

如果 $Keywords$ 对您来说至关重要，那么也许您可以尝试查看 Mercurial ？ 它有一个 hgkeyword 扩展来实现你想要的。 无论如何，Mercurial 作为 DVCS 很有趣。

Answer 8

使用 Git 存储库完成的事情是使用 tag 对象。 这可用于用任何类型的字符串标记提交，并可用于标记版本。 您可以使用 git tag 命令查看存储库中的标签，该命令会返回所有标签。

检查标签很容易。 例如，如果有一个标签 v1.1 您可以将该标签签出到分支，如下所示：

git checkout -b v1.1

由于它是顶级对象，因此您还将看到该提交的整个历史记录能够运行差异、进行更改和合并。

不仅如此，即使标签所在的分支已被删除而没有合并回主线，标签仍然存在。

Answer 9

要将扩展应用到存储库中所有子目录中的所有文件，请将 .gitattributes 文件添加到存储库中的顶级目录（即通常放置 .gitignore 的位置） 文件）包含：

* ident

要查看其效果，您需要首先对文件进行有效的签出，例如以任何方式删除或编辑它们。 然后使用以下命令恢复它们：

git checkout .

您应该会看到 $Id$ 替换为以下内容：

$Id: ea701b0bb744c90c620f315e2438bc6b764cdb87 $

来自 man gitattributes：

身份

当为路径设置属性 ident 时，Git 会替换路径中的 $Id$
带有 $Id: 的 blob 对象，后跟 40 个字符的十六进制 blob 对象
结账时，名称后面加上美元符号 $。 任何开始的字节序列
工作树文件中以 $Id: 结尾并以 $ 结尾的内容在签入时替换为 $Id$。

每次提交新版本的文件时，此 ID 都会更改。

Answer 10

现在，Git 可以通过 gitattributes(5) 的 export-subst 功能将标签名称和其他相关信息直接自动编辑到文件中。 这当然需要使用 git archive 来创建版本，并且只有在生成的 tar 文件中，替换编辑才可见。

例如，在 .gitattributes 文件中添加以下行：

* export-subst

然后在源文件中，您可以添加如下行：

#ident  "@(#)PROJECTNAME:FILENAME:$Format:%D:%ci:%cN:%h$"

在由例如 git 存档 v1.2.0.90：

#ident  "@(#)PROJECTNAME:FILENAME:HEAD -> master, tag: v1.2.0.90:2020-04-03 18:40:44 -0700:Greg A. Woods:e48f949"

Answer 11

如果我理解正确的话，本质上，您想知道自上次更新以来给定文件发生了多少次提交。

首先获取远程源中的更改，但不要将它们合并到您的 master 分支中：

% git fetch

然后获取 master 之间给定文件上发生的更改的日志> 分支和远程origin/master。

% git log master..origin/master foo.el

这将为您提供自您上次将 origin/master 合并到 master 以来远程存储库中发生的所有提交的日志消息。

如果您只想要更改的计数，请将其通过管道传输到 wc。 说吧，像这样：

% git rev-list master..origin/master foo.el | wc -l

Answer 12

如果您只是希望人们能够了解他们的内容已经过时了多少，Git 可以通过几种相当简单的方式告知他们这一点。 例如，他们会比较他们的主干和您的主干上最后一次提交的日期。 他们可以使用 gitcherry 来查看有多少提交发生在你的行李箱中但不存在于他们的行李箱中。

如果这就是您想要的，我会寻找一种无需版本号即可提供它的方法。

另外，除非你确定他们想要，否则我不会向任何人表示礼貌。 :)

Answer 13

如果您希望 git 提交信息可访问到您的代码中，那么您必须执行预构建步骤以将其获取到那里。 在 C/C++ 的 bash 中，它可能看起来像这样：

prebuild.sh

#!/bin/bash
commit=$(git rev-parse HEAD)
tag=$(git describe --tags --always ${commit})
cat <<EOF >version.c
#include "version.h"
const char* git_tag="${tag}";
const char* git_commit="${commit}";
EOF

和 version.h 看起来像：

#pragma once
const char* git_tag;
const char* git_commit;

然后，无论你在代码中需要它 #包含“version.h”并根据需要引用git_tag或git_commit。

您的 Makefile 可能包含如下内容：

all: package
version:
  ./prebuild.sh
package: version
  # the normal build stuff for your project

这样做的好处是：

• 为 this 构建获取当前正确的值
  无论分支、合并、樱桃采摘等。

prepublish.sh 的这种实现有以下缺点：

• 即使 git_tag/git_commit 没有更改，也会强制重新编译。
• 它不考虑尚未提交但影响构建的本地修改文件。
  • 使用 git describe --tags --always --dirty 来捕获该用例。
• 污染全局命名空间。

可以避免这些问题的更高级的 prebuild.sh 留给读者作为练习。

Answer 14

RCS ID 对于单文件项目很有用，但对于任何其他项目，$Id$ 没有说明该项目（除非您对虚拟版本文件进行强制虚拟签入）。

还有人可能感兴趣如何在每个文件级别或提交级别获取 $Author$、$Date$、$Revision$、$RCSfile$ 等的等效项（如何将它们放在某些关键字所在的位置是另一回事）问题）。 我对这些没有答案，但看到更新这些的要求，特别是当文件（现在在 Git 中）源自 RCS 兼容系统 (CVS) 时。

如果源代码与任何 Git 存储库分开分发（这也是我所做的），那么这样的关键字可能会很有趣。 我的解决方案是这样的：

每个项目都有自己的目录，在项目根目录中我有一个名为 .version 的文本文件，其内容描述了当前版本（导出时将使用的名称）来源）。

在开发下一个版本时，脚本会提取 .version 编号、一些 Git 版本描述符（例如 gitdescribe）以及 .build（加上主机和日期）到链接到最终程序的自动生成的源文件，这样您就可以找出源代码以及构建时间。

我在单独的分支中开发新功能，我做的第一件事是将 n （表示“next”）添加到 .version 字符串（源自同一根的多个分支）将使用相同的临时 .version 编号）。 在发布之前，我决定要合并哪些分支（希望所有分支都具有相同的 .version）。 在提交合并之前，我将 .version 更新为下一个数字（主要或次要更新，具体取决于合并的功能）。

Answer 15

我同意那些认为令牌替换属于构建工具而不是版本控制工具的人。

您应该有一些自动发布工具来在标记版本时在源中设置版本 ID。

Answer 16

我也来自 SCCS、RCS 和 CVS (%W% %G% %U%)。

我也遇到过类似的挑战。 我想知道一段代码在运行它的任何系统上是什么版本。 该系统可能连接也可能不连接到任何网络。 系统可能安装也可能没有安装 Git。 系统可能安装也可能没有安装 GitHub 存储库。

我想要针对多种类型的代码（.sh、.go、.yml、.xml 等）使用相同的解决方案。 我希望任何不了解 Git 或 GitHub 的人都能够回答这个问题“您正在运行什么版本？”

因此，我围绕一些 Git 命令编写了所谓的包装器。 我用它来标记一个文件的版本号和一些信息。 它解决了我的挑战。 它可能对你有帮助。

https://github.com/BradleyA/markit

git clone https://github.com/BradleyA/markit
cd markit

Answer 17

如果像OP一样，您使用Emacs，则可以使用它的时间戳
函数来获取您想要的自动属性更新。

让您的编辑进行更新的优点是
文件内容更新时时间戳
更改，而不是当某人仅仅将文件提交到
版本控制或重建。

$Id$ 模板的时间戳等效为 Time-stamp: <>
并且，与 $Id$ 不同，它必须出现在文件的前 8 行内。

您需要在 Emacs init 文件中启用自动时间戳，
您可以这样做：

M-x customize-variable RET
before-save-hook RET

选中时间戳框并选择应用并保存。

Answer 18

既然你使用 Emacs，你可能会很幸运:)

我碰巧遇到了这个问题，也碰巧我来到了 Lively 几天前，一个 Emacs 包，允许在文档中包含生动的 Emacs Lisp 片段。 老实说，我没有尝试过，但读到这篇文章时我就想到了这一点。

Answer 19

为了自己解决这个问题，我创建了一个小的“hack”作为提交后钩子：

echo | tee --append *
git checkout *

更详细的记录在 我的博客上的这篇文章。