Christian Couder <christian.couder@xxxxxxxxx> writes: > What scenario do you have in mind where people would have to do things > differently? They eventually will see a system in which that they do not have do anything after flipping the configuration, yet will still see stale "you must run 'git status'" on their websearches and SO questions, which would be a cost for them to remember that they no longer have to do the extra 'git status'. >> Itt sounds like somewhat a short-sighted mindset to design the >> system, and I was hoping that by now you would have become better >> than that. >> >> The real question is what are the problems in implementing this in >> the way Duy suggested in the previous discussion. The answer may >> fall into somewhere between "that approach does not work in such and >> such cases, so this is the best I could come up with" and "I know >> that approach is far superiour, but I have invested too much in this >> inferiour approach and refuse to rework it further to make it better." > > My question is why should I invest time thinking about and testing > another approach when the current approach seems simpler, less bug > prone, faster and without any downside? As to the downside, I think Duy's "at the time we read the index" is the least problematic route from the maintainability point of view. What are you doing to help people who make changes in the future to the system to make "git add $dir" or "git clean $dir" aware of the untracked cache not to forget doing the "oh, the config says we want to add the untracked cache if missing, so we do it here" in their new codepath? Whey you say "This is only about status", you are essentially saying "It's outside the scope of my job, I was hired to improve the usability of 'git status' with untracked cache and I do not care about the longer term overall health of the system". Now, you said something about "simpler", "less bug prone" and "faster" (I doubt you can make such statements that involve comparison without investing time thinking about other approaches, though, but that is a separate topic). That would mean that you see "complexity", "error prone-ness", and "slowness" in the way Duy suggested---that is exactly the question I asked you in the message you are responding to. What are the problems in implementing this in the way Duy suggested? What kind of "complexity" do you see? Which part is more "error prone"? Why does it have to be "slower"? >> Using of not using untracked-cache is (supposed to be) purely >> performance and not correctness thing, and I do not think the users >> and the scripts do not deserve to see a failure from "update-index >> --untracked-cache" only because there is a stray core.untrackedCache >> set to 'false' somewhere. > > This "stray core.untrackedCache" could not have been put there by > users of previous git versions because it has no meaning before this > patch series. So I don't understand why you call it "a stray > core.untrackedCache". > > It is no more "stray" to me than the call to "update-index --untracked-cache". > > If it has been put in /etc/git.config by an admin and if the user > thinks he knows better, the user can still change the config locally > to override the system one. You are assuming that everybody constantly looks at /etc/git.config to make sure evil admins won't do things that affect their repositories and use of Git in potentially negative way. I doubt anybody does. By the way, I understand that this "stray one affects without user being aware of it" is the primary the reason why Ævar wants this 'configuration automatically adds untracked cache even to the existing index' feature---everybody will get it without even be aware of the change their admins make. Which may be a good thing for those who use the configuration variable. -- 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