On Wed, 18 Apr 2007, Linus Torvalds wrote: > > > On Wed, 18 Apr 2007, Rogan Dawes wrote: > > > > Or similarly, when checking an "ODF" file in, the attribute would lead to an > > appropriate script creating the "tree" of individual files. > > > > Does this sound workable? > > I think it sounds very interesting, and I'd much rather do _those_ kinds > of rewrites than keyword unexpansion. And yes, some kind of generic > support for rewriting might give people effectively the keywords they want > (I think the CVS semantics are not likely to be logical, but people can > probably do something that works for them), and at that point maybe the > keyword discussion goes away too. Exactly my point. > However, I don't know if it is "workable". > > The thing is, it's easy enough (although potentially _very_ expensive) to > run some per-file script at each commit and at each checkout. But there > are some fundamental operations that are even more common: > > - checking for "file changed", aka the "git status" kind of thing > > Anything we do would have to follow the same "stat" rules, at a > minimum. You can *not* afford to have to check the file manually. > > So especially if you combine several pieces into one, or split one file > into several pieces, your index would have to contain the entry > that matches the _filesystem_ (because that's what the index is all > about), but then the *tree* would contain the pieces (or the single > entry that matches several filesystem entries). For that the external script would need the ability to alter the index itself. That becomes a bit yucky. Or maybe something could be made with a mechanism like dnotify/inotify to "touch" the single placeholder entry referenced by the index whenever one of the split component changes. > - what about diffs (once the stat information says something has > potentially changed)? You'd have to script those too, and it really > sounds like some very basic operations get a _lot_ more expensive and > complex. Of course an attribute for external diff script is certainly something that could be useful independently of this case, as some particular binary formats might have a way of their own to display their differences. The whole idea of having the ability to call external tools is exactly to delegate complex/bizarre/unusual tasks to separate and independent agents. The whole checkout operation becomes much more expensive but everyone using such facility might expect it. It just cannot be as bad as a straight checkout with CVS from a remote server though (OK I know it can but you know what I mean). > This is also related to the above: one of the most fundamental diffs is > the diff of the index and a tree - so if the index matches the > "filesystem state" and the trees contain some "combined entry" or > "split entry", you'd have to teach some very core diff functionality > about that kind of mapping. Well, if the split components are represented by a single placeholder in the index and the filesystem, and the filesystem placeholder is "touched" whenever a split component is modified, then the mapping can as well be limited to the external scripts for checkin/checkout/diff only without the Git core having the slightest idea about it. Sure it might be slow and unusual, but at least not impossible. And again, with an attribute providing a facility for external tools it is then not our problem anymore. Nicolas - 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