Re: Weird shallow-tree conversion state, and branches of shallow trees

On Sun, 15 Apr 2007, Robin H. Johnson wrote:

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