I'm planning my company's transition from CVS to Git, and certain engineers are wishing we still had use of CVS keyword strings such as $Id: $
. I have read all about implementing this with the ident setting .gitattributes
, and I understand why it's undesirable, though maybe possible for smaller source trees. (Our source is huge, so I think it would be impossible.)
Our engineers don't particularly care about having the SHA1 hash in the file. They just want to know:
- the date of last modification
- the name of the committer
- possibly the commit message
They find it extremely handy to see this info in file headers when browsing code, and I can't argue with that.
What I want to know is:
Is there any way to info-stamp all the staged files at the moment before git commit? In other words, to run a perl command -- that replaces $Id: $
with a block of desired info -- on the working copies of files being committed?
This wouldn't require any .gitattributes
actions at all. Git would just need to know how to merge two such blocks of info, ideally by choosing the later one. The stamped info would be just one more file change in the newly created version.
I looked at doing this in the pre-commit hook, but it seems to be intended differently -- not for editing files, just for checking them. Am I right about that?
And has nobody tried this approach? It seems simpler to me than trying to filter all source files every time git changes versions, which it what it sounds like .gitattributes
does.
Much thanks for any advice/warnings/pointers .