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

From: Nicolas Pitre <nico@cam.org>
Date: Apr 18, 2007, 15:34 UTC
Message-ID: <alpine.LFD.0.98.0704181114040.4504@xanadu.home>
In-Reply-To: <alpine.LFD.0.98.0704180748460.2828@woody.linux-foundation.org>

On Wed, 18 Apr 2007, Linus Torvalds wrote:

Show 15 quoted lines

> 
> 
> 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.

Show 16 quoted lines

> 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).

Show 5 quoted lines

>    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