Hi,
I was just wondering whether we want to use something similar to the
$Id$ keyword for git. If not, we should probably remove all the $Id$
lines in the code....
It's seems it's deliberately not supported in git. However,
gitattributes(5) can be used to embed a "blobid" (which basically is the
SHA-1 of the file's contents when it was committed). There's also a
"filter" feature in gitattributes that could be used to hack something
together, but it's probably a bad idea.
Why is it not in git:
http://thread.gmane.org/gmane.comp.version-control.git/44750
gitattributes:
http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
cu
gregor
However, gitattributes(5) can be used to embed a "blobid" (which basically is
the SHA-1 of the file's contents when it was committed).
Is there an example where anyone would care to look at that? The git log seems like a better place to turn to. My opinion would be to ditch the keyword substitutions.
- Jon
Why is it not in git:
http://thread.gmane.org/gmane.comp.version-control.git/44750
Um, that's a 50-100 message thread - care to summarize it for us?
Vern
I'll try (I've only skimmed over the thread)
* Problematic with git's approach of addressing and tracking
*content* (because the same file-content, identified by its SHA-1
can be present in many different commits. A commit points to a file's
content, but given a file-content, there can be any number of commits
associated with it)
* It can break diffs (if the keyword line is part of the context and
and the keywords are different (e.g., due to different branches))
* performance. Keyword expansion is expensive
* Linus Torvalds hates them
I seems that this mail covers most of the arguments (it's kinda longish)
http://article.gmane.org/gmane.comp.version-control.git/44654,
Another argument is, that if keywords are desired, they should be added
when a file is exported from revision control (so that it's in the tarball)