David Lang <david.lang@xxxxxxxxxxxxxxxxxx> 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...". 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". 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? - 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