oxcrete <oxcrete@xxxxxxxxx> writes: > 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---H and 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! ;-) -- Jakub Narebski Poland ShadeHawk on #git -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
