On Tuesday 2007, April 17, Linus Torvalds wrote: > So you will never work with anybody outside of git? For my projects - correct; I don't care about the rest of the world. For projects that do - don't enable keywords, it's an option, all I want is to have that option. > What about tar-files when you export the tree? Should they have the > expanded version? If I have to pick one then: no. I think out-of-tree keywords are too much trouble for exactly the reasons you say; however, I wouldn't like to presume what other people think is too much trouble so I suppose it would have to be an option. > > You keep saying these sweepingly general things. It can be made to > > work. > > No, it CANNOT. > > Trust me. There's NO WAY IN HELL it will "work" in any other sense > than "limp along and not be usable". Well I'm making progress, "limp along" is a significant step up from impossible. :-) Look, my primary objection to this is the SHOUTING about how impossible it is even though I've tried to address every problem you've thrown at me - I'm finding it really difficult to figure out why you're trying so hard to dissuade me from even _trying_. If it all goes wrong (as I fully accept it might), so be it, I can live with that; I'll even be happy to tell you you're right and I'm wrong. Why is this such a problem? Keywords are so hated by everyone that I doubt they would ever be accepted into git - it's an intellectual exercise for me at this stage really. > Yes, you can make it "work" if you: > > - make sure that you never _ever_ leave the git environment As it happens, _I_ never ever leave the git environment. Can I use keywords then? You don't seem to have such a problem with git's extended diffs for renames or subprojects - "make sure that you never _ever_ leave the git environment". > But why do you want keyword expansion then? The whole point is if > you have other tools than the git tools that look at a file. Even > your svg example was literally about having non-git tools work with > the data. What if you ever email the file to somebody else? If by "tools" you mean other version control systems, then I don't intend them to work. If by "tools" you mean gcc, inkscape, gv, bash, web browsers or any other fileformat that allows comments in the file then I expect it to be fine. If I publish a web page, it'd be nice to show the ID on the page - that's all just "nice" not "necessary" or "I'm throwing git away if I don't get it". Emailing to others isn't a problem either: let's say I email them my SVG (with keywords expanded), they make some edits and send it me back - worse, they send me a diff back. I'm going to apply that diff using git-apply; which will collapse the keywords and apply the diff. > - you make all git tools explicitly always strip them. Well, not "all", so far I've added one call to convert_to_git() in builtin-apply.c - it was a one line addition. It needed doing anyway to deal with the CRLF correctly. I can't see there being that many places that this needs doing. I may well be wrong, if I end up scattering calls to convert_to_git() everywhere I'll give up. > Again, what's the point again? You add keyword expansion, and then > the only tools that you really allow to touch it (except your "print > it out" example) will have to remove the keyword expansion just to > work. (I don't see why my tiny "print it out" example isn't enough - it matters to me) However, most tools don't care about the keywords, it's only non-git diff and non-git patch that are affected. As long as the file format supports comments, then keyword expansion will be just fine. > That's not "work". That's just stupid. Yes, you can make your "print > it out" example work, but as alreadyt mentioned, you could have done > that some other way, with a simple makefile rule, quite independently > (and much better) than the SCM ever did. That's just being obtuse - no other tool cares in the slightest about the keywords, there are more "tools" in the world than just the VCS. 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