Jeff King <peff@xxxxxxxx> writes: > On Sun, Nov 29, 2009 at 11:28:27AM +0100, Johannes Schindelin wrote: > ... >> > When the number of "git grep" crash fatalities rises above zero, maybe >> > this line of reasoning will be relevant. >> >> Sure. Let's wait for the first crash fatality, and only react then. No >> need to think ahead. > > ... The actual situation > at hand is a git grep configuration variable. I am weighing the > preference of people who use git every day and want it to work in a > certain way against the possibility that somebody helping them will be > slightly inconvenienced or surprised. While my position is *not* "hurting people who help is too grave and we shouldn't even weigh other upsides against it---bad is bad is bad, and it is absolutely bad" (which is what I think Dscho is saying), I think "slightly inconvenienced or surprised" is trying to make it sound a lot lighter than it is. Imagine you are helping somebody to track down a bug in a project whose source happens to be under git. You two scratch your heads together, and you try to find if the function you are fixing have other call sites, and you run "git grep" to find them. You think you covered the whole tree, identified all the callsites and made sure that the updated behaviour of the function with your fix is consistent with all of them. But it turns out that you didn't check the whole tree, due to user's configuration, and you didn't notice. You can easily waste 30 minutes of two people until you realize what happened. Because the whole point of your grep.fulltree configuration is that you can set it once and forget about it, even after you noticed that your grep didn't look in the whole tree as you expected, the configuration variable is not the first thing that will come to your mind. You will waste more minutes wondering why grep is not working as you expect, until you finally come up with a suggestion to set the configuration to make grep look in the full tree by default in her repository. Put it another way, your "I can set it and forget about it" may be a way to solve "differentiating two things is a mental burden and I do not want to think about it". But I do not think the "mental burden" problem is necessarily what we want to solve. The "set and forget" will bring confusion. The best solution to the "mental burden" problem may not even be "I can set it and forget about it". An obvious solution to that problem, that is far easier to explain, is not to have two things to begin with, and that is what we do: "If you want to grep in the whole tree, you go to the top and run grep there." Of course, its downside is that it is often cumbersome to "got to the top" when you are somewhere deep. That is why I think it would be a lot better solution to spend our efforts making sure that both semantics can be called for from the command line in a concise and clear way. IOW, the problem I see worth solving first is not the "mental burden" problem, but is "differentiating two things is necessary, but it is cumbersome to say which one I want." You probably can add both configuration and concise command line syntax, but "solving" the "mental burden" problem will make you forget about the need to use --full-tree option (or its quivalent that will happen in the solution of the "cumbersome to say which one I want" problem). On the other hand, not "solving" the "mental burden" problem will hopefully train your brain and your fingers to always be aware of and to say which one you want, to the point that you do not even have to think. For that to happen, "cumbersome to say which" problem must be solved nicely, of course. > ... Something that will happen much > less frequently than the person actually _using_ git, and something > which has much smaller negative consequences than people dying. It is of course not _fatal_, but there are not many things that are fatal. Saying "that is not fatal so it is Ok" is not particularly a good way to weigh downsides against upsides. -- 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