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

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

David Lang [off-list ref] writes:

quoted

quoted

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

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