On Sunday 2007, April 15, Linus Torvalds wrote: > Keyword substitution is just *stupid*. It's an inexcusable > braindamage. Don't do it. It leads to all kinds of idiotic problems > downstream, and it really doesn't help *anything* except for "but I'm > used to it". There are absolutely no valid uses for it. You're right that it can cause problems, but it is certainly not the case that there are no valid uses for it. I've mentioned it before but I'll say it again, because it is the only feature I miss from subversion and I can't see why it is invalid. I keep diagrams for a project in SVG format in the repository, this works very well because SVG is so nicely ASCII. In the title block of the diagram I put "$Id$", then in subversion, after checking in and updating it got expanded to $Id: diagram.svg 148 2002-07-28 21:30:43Z andyp $ Now, I print out that diagram and pin it to my wall - sometimes copies of it are given to others. I do this on a regular basis. The diagram is big and complicated and all versions of it look very similar. In short it is very convenient to have the version of the file actually printed on the piece of paper. This is a piece of paper remember, there is no way to hash the daigram, or even look at the underlying source. When someone comes to me with a random version of the diagram, I can use that ID to checkout exactly the revision that that diagram refers to. Please explain to me why that is not a valid use. > If you want to tag your files somehow, do it in "git archive" when > exporting it, but not in the working tree. And realize that once you > export it with the stupid keyword expansion, diffs etc will all be > corrupted, and will not - AND MUST NOT - apply to the uncorrupted > working tree. All of the problems you describe apply equally to CRLF conversion, and yet there seems to be no problem with implementing that. In fact the problem there is significantly worse, as it changes every line of the file. Now, solving the keyword problem is not simple, obviously, but it's certainly not impossible. On git-add the expanded tags get unexpanded so $Tag: blah blah blah$ becomes $Tag$; on checkout they get expanded. Similarly while calculating diffs - the diff engine unexpands as it goes so the lines with the keywords in them are not seen as different regardless of the expanded part. Applying diffs from some external source doesn't corrupt anything - because the diff engine is, by definition, going to unexpand the keywords when it compares. So, someone sends you a diff that has this: - /* $Id: diagram.svg 148 2002-07-28 21:30:43Z andyp $ */ + /* $Id: diagram.svg 149 2002-07-29 20:32:47Z andyp $ */ And you apply it to the working tree - well, that line will be seen as this by the diff engine: - /* $Id$ */ + /* $Id$ */ No change. Obviously this is entirely optional and would be activated on a per-file basis. For git it would be even more useful because of all the information actually available. I'd love to have git-keywords like these: $Commit: 2bfe3cec92be4f5e3bfc0e71ed560df4a726c07b$ $Object: b1bd9e46c2bd64e00b671ff5ed512d9c12b53309$ $Describe: v1.5.1.1-83-g2bfe3ce$ $Id: cache.h v1.5.1.1-83-g2bfe3ce $ Feelings seem very strong about this; I've seen comments again and again about how braindamaged it is and I just can't see it - please, help me see - what is it that is so utterly broken about it? I can see that it adds a complication to many parts, but I can't see why it is seen as so evil. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@xxxxxxxxx - 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