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

[Andy Parkins <andyparkins@gmail.com>]

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@gmail.com