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

From: David Lang <david.lang@digitalinsight.com>
Date: Apr 21, 2007, 23:31 UTC
Message-ID: <Pine.LNX.4.63.0704211620250.5655@qynat.qvtvafvgr.pbz>
In-Reply-To: <7vbqhiwky4.fsf@assigned-by-dhcp.cox.net>

On Fri, 20 Apr 2007, Junio C Hamano wrote:

Show 21 quoted lines

> David Lang <david.lang@digitalinsight.com> writes:
>
>>> But with keyword expansion and fancier "external tools" whose
>>> semantics are not well defined (iow, defined to be "do whatever
>>> they please"), does it still make sense to consider two blobs
>>> that appear in totally different context "the same" and omit
>>> checking out (and causing the external tools hook not getting
>>> run)?  I already pointed out to Andy that the branch name the
>>> file was taken from, if it were to take part of the keyword
>>> expansion, would come out incorrectly in his printed svg
>>> drawing.
>>
>> this is part of the rope you are handing out. the external tool could
>> do a lot of things that don't make sense. you could have the tool
>> include the serial number of the cpu you happen to be running on at
>> the moment, it wouldn't make sense to do this, but it could be
>> done. the fact that the rope could be used to hang someone doesn't
>> mean that you should outlaw rope.
>
> I do not think you understand, especially after reading the part
> you say "Andy and I both...".

sorry for not being clear

Show 11 quoted lines

> The point of my comment was that with Andy's definition of when
> the "external tools" should trigger, that CPU serial number
> embedder would _NOT_ trigger for a path when you switch branches
> that have the same contents at that path.  External tools can do
> stupid things and that is what you are calling the rope.  But
> the case I am talking about is that we deliberately do _not_
> call external tools, so even if external tools can do sensible
> things if given a chance to, they are not given a chance to do
> so, and deciding not to call them in some cases is made by us.
> I think that's different from "we gave you rope, you hang
> yourself and that is not our problem".

the cpu serial number would be different for each cpu in a system, so you could get different answers, even in the same branch (let alone on different systems, which is what I was thinking of when I wrote that example)

my point was that while it's possible to define external tools that will cause problems (my having effectvly random changes to the files), and when external tools are used it will slow things down (how much depends on the tools), it's also possible to define external tools that only have well defined, easily reversable effects, that only touch a few files, and so don't cause a huge performance hit.

> People have every right to say "if you consistently call these
> external tools, they behave sensibly, but you only call them
> when you choose, and that is where the idiocy is coming from".
> How would you respond to that?

consistantly calling the external tools is not the same thing as calling them for every possible thing that refrences the file, it's calling them every time a particular type of access to the file is made (and it helps to have well defined and well documented rules for when they are used)

I think the basic rule of 'git commands work against the checked-in version of the file' is a solid basis to work from. This means that you can't optimize by sometimes looking at the checked-out version, and there may still be some corner cases to explain/clarify/define (like the git-diff against the working tree mentioned in other messages)

David Lang