On Sun, 15 Apr 2007, Robin H. Johnson wrote: > > Nobody has addressed the single problem that I have with adding it when > it's leaving the environment, and that's still of paramount concern to > me. Simply put, there is a conflict between being able to add revision > information of stuff leaving the environment, and those additions > breaking previous checksums (which may be digitally signed, and thus > breaking the signatures). Don't be silly. You can just checksum without the ID. Which you have to do with git anyway, since any expanded ID *itself* would be part of any ID, which means that under git, you *physically*cannot* make an ID string be part of the source control environment anyway, unless you did the SHA1 while ignoring the $Id$ expansion. In other words, the problem you talk about exists *regardless*. You suggest pushing that problem into the SCM layer, and de-stabilizing the SCM and causing EVERYBODY ELSE provlems. And I'm telling you that if you want the idiocy of keyword expansion, you can have it, BUT YOU CANNOT HAVE IT IN THE SCM. Because *every* *single* problem you have with keyword expansion (whether it be checksums or anything else) will be MUCH MUCH worse if you do it at the SCM level! Really. When you talk about your "single problem", why the HELL do you think that problem goes away just because you try to deal with it inside the SCM? Trust me, the problem does *not* go away, it gets *bigger*. You're trying to push it into the SCM, because _you_ don't want to deal with the inevitable problems that keywords cause. But face it, the SCM wants to deal with them *even*less*, because they are much worse there, and more importantly, you'd be trying to push them into a level where most users have gotten over the braindamage and no longer want it! So you're trying to make *everybody* suffer, just because you cannot do it right. And suffer people do. There's a reason people are so negative about keyword expansion: we've _seen_ those problems first-hand. So the proper solution is: - don't do keyword expansion on the "originals". - add release information when you do a release. - if you want to sign releases, do so *after* the release. That's what a release process is all about. - if you're so damn lazy that you can't be bothered to do the signing of the release, don't ask others to do stupid things because *you* do something stupid - just make sure that whatever release information you add can be *removed*, so that you can verify an exact match. For example, look at how "git archive" does this. It actually adds release information to the tar-file. It's hidden as a magic header, but that also means that since it's *separate* from the source code, it avoids all the problems with keyword expansion, and now you can (for example) diff the tar-ball source tree with the git tree, and you will not get spurious AND INCORRECT differences! And any checksums would still be valid! And the same kind of thing can be done even if you absolutely have to embed the information on a file-by-file basis. Just make sure that you do it in some reversible manner. But preferably you generate a separate file (eg my hypothetical Makefile example that actually generates a "prt" file from a "svg" file) so that you have the original and can do any diff or validation efforts on *that*. Linus - 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