Summary: The recommended way of embedding version information in a product is to use the build system for that; see below for details and alternate approaches.
In Git (and I think usually also in other VCS systems with atomic commits) there is no such thing like version of a single file.
Git does support on-demand expansion of $Id:$
keyword, but:
- It is done on request only. You have to specify (perhaps using globbing pattern) that a file (or a set of files) has an
ident
attribute set (in '.gitattributes' file in tree, or in '.git/info/attributes' for local repository settings).
- It expands to the SHA-1 of file contents (or to be more exact to
$Id:<sha-1 of blob>$
). The reason for this choice is that Git does not touch files that have not changed during branch switching or rewinding; if '$Id:$' expanded to revision info it would require to update every version-controlled file e.g. when switching branches.
Git supports quite a wide set of $Format:...$
placeholders which expands to commit information (e.g. $Format:%H$
replaced by a commit hash) but:
- Expansion is done only when running git archive, in its output file.
- It is done on request, controlled via
export-subst
attribute.
The recommended way of embedding version information is to do it via the build system (in a build stage); see for example Git Makefile and GIT-VERSION-GEN script used by Makefile in the Git web interface for the git.git repository.
You can however (ab)use a clean/smudge filter driver (via filter
attribute) to get CVS-like keyword expansion, expanding keywords on checkout, and cleaning them up on entering contents to the repository.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…