auto insert history info into source files, at commit?
How do you do this with Git? I couldn't find it in the documentation. the standard $Log, $revision... didn't seem to work. I'll take an RTFM answer if you can point me to the right section in the manual. Appologies, if this was posted before - couldn't find a good regex to search this topic.
Signature · 2 lines
View this message in context: http://www.nabble.com/auto-insert-history-info-into-source-files%2C-at-commit--tp16562665p16562665.html Sent from the git mailing list archive at Nabble.com.
Quoted 5 lines · oxcrete
How do you do this with Git? I couldn't find it in the documentation. the standard $Log, $revision... didn't seem to work. I'll take an RTFM answer if you can point me to the right section in the manual. Appologies, if this was posted before - couldn't find a good regex to search this topic.
http://git.or.cz/gitwiki/GitFaq#head-4a0afe71a2bb7734777a8b0b345e0308aefdbd40
Santi
Quoted 4 lines · oxcrete
How do you do this with Git? I couldn't find it in the documentation. the standard $Log, $Revision... didn't seem to work. I'll take an RTFM answer if you can point me to the right section in the manual. Appologies, if this was posted before - couldn't find a good regex to search this topic.
http://git.or.cz/gitwiki/GitFaq#head-4a0afe71a2bb7734777a8b0b345e0308aefdbd40
"Does git have keyword expansion?" (and also next section, "Does git allow arbitrary conversion of contents?")
Simply said keywords do not work well together with nonlinear history, and especially with the way git is engineered, being content-adressed. If you have the following history:
A---B---C---D---E
\
\-F---G---Hand the file 'foo' has the same contents in both branches, in both E and H commits (revisions), it would be noticed by git and it wouldn't touch this file when switching branches. It is one of the keys to git performance. This is important not only for switching branches, but also for merging.
But if they have $Revision$, or $Author$ keywords, and those would be different, it couldn't be done this way.
Therefore git supports "keyword expansion" in three ways, beginning from simplest.
1. The ident attribute, which allows to expand $Id$ to $Id: <sha-1>$, where <sha-1> is blob (file contents) identifier.
2. The export-subst attribute, and/or various tricks in Makefile, which allow embedding information about current revision (like result of "git describe") in files when using "git archive" (atribute), or "make" / "make dist". This is I think the preferred way; both git and Linux use Makefile tricks to embed version info in result of compilation.
3. Use filter attribute to expand keywords when checking out file, and removing keywords when commiting changes (but watch for binary files!). This would affect performance. I also don't think that there is any example doing keyword expansion with filter gitattribute; you can be first! ;-)
Signature · 3 lines
Jakub Narebski Poland ShadeHawk on #git