3 ms·

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

• JoshTriplett 7y ago
  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).
• vhakulinen 7y ago
  Is that somehow fundamentally different from "git describe --tags --always"?
  • goatinaboat 7y ago
    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”?
• bluGill 7y ago
  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.