git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
APAndy Parkins <andyparkins@gmail.com>
Date
Apr 15, 2007, 19:51 UTC
Message-ID
<200704152051.35639.andyparkins@gmail.com>
In-Reply-To
<Pine.LNX.4.64.0704151115270.5473@woody.linux-foundation.org>
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.
Show 5 quoted lines
> 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
Previous: Linus TorvaldsNext: Linus Torvalds
Message 10 of 34 in “Weird shallow-tree conversion state, and branches of shallow trees”
  1. Robin H. JohnsonApr 12, 2007
  2. Johannes SchindelinApr 14, 2007
  3. Robin H. JohnsonApr 15, 2007
  4. David LangApr 15, 2007
  5. Robin H. JohnsonApr 15, 2007
  6. Shawn O. PearceApr 15, 2007
  7. Nguyen Thai Ngoc DuyApr 15, 2007
  8. Jakub NarebskiApr 15, 2007
  9. Linus TorvaldsApr 15, 2007
  10. Andy ParkinsApr 15, 2007
  11. Linus TorvaldsApr 15, 2007
  12. Bill LearApr 16, 2007
  13. Andy ParkinsApr 16, 2007
  14. Julian PhillipsApr 16, 2007
  15. Robin H. JohnsonApr 16, 2007
  16. Theodore TsoApr 16, 2007
  17. Nguyen Thai Ngoc DuyApr 16, 2007
  18. Linus TorvaldsApr 16, 2007
  19. Nguyen Thai Ngoc DuyApr 16, 2007
  20. Robin H. JohnsonApr 16, 2007
  21. Linus TorvaldsApr 16, 2007
  22. Daniel BarkalowApr 17, 2007
  23. Linus TorvaldsApr 16, 2007
  24. Andy ParkinsApr 16, 2007
  25. Sven VerdoolaegeApr 16, 2007
  26. Linus TorvaldsApr 16, 2007
  27. David LangApr 16, 2007
  28. David LangApr 17, 2007
  29. Andy ParkinsApr 17, 2007
  30. Junio C HamanoApr 16, 2007
  31. Andy ParkinsApr 16, 2007
  32. Junio C HamanoApr 17, 2007
  33. Andy ParkinsApr 17, 2007
  34. Robin H. JohnsonApr 15, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.