Hacker News Reader

Comment by beefhash | Hacker News Reader

Once upon a time, we had version control systems that provided keyword expansion for something like %G% (SCCS, BitKeeper) or $Id$ (RCS, CVS come to mind). With git, this has fallen out of fashion, however, but I'm not sure why.

View on HN

I'm glad it is gone. The useful uses of it are far outweighed by the abuses. If I never again have to page down through the entire history of a file in my editor to get to the code that will be fine with me. I have a version control system when I need to know history.

git still supports a variant of that (if you set the "ident" flag in gitattributes), though it uses the blob hash of that file, not the commit hash.

But in general, git doesn't look kindly on gratuitous modifications to source files. Those modifications can never occur in the actual files in the repository, since you can't hash something that contains its own hash (unless the hash is broken). And having the file in the working directory not match the file in the repository makes life difficult in various ways (diffs, etc).

Is that somehow fundamentally different from "git describe --tags --always"?

Yes. When you checked a file into VSS it would expand the string $Id$ before actually writing the file into the repo, so it would be in the file you checked out. So if you had a copy of that file, you could know instantly what revision it was from. If you had blah.c on your disk and you had a Git repo it’s far harder to say “what commit did this copy of the file actually come from”?

Reply on news.ycombinator.com