Re: [PATCH 2/2] Add keyword unexpansion support to convert.c

On Wed, 18 Apr 2007, Linus Torvalds wrote:

On Wed, 18 Apr 2007, Rogan Dawes wrote:

quoted

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