Jeff King <peff@xxxxxxxx> writes: >> What remains is the downside of the configuration variable, >> namely, that it makes git behave differently depending on who you are and >> in which repository you are using it, hence making it harder to help >> and/or teach others. > > I have never been a fan of this reasoning. Sure, it is slightly harder > to help people when the system is configurable. But dropping > configurability comes at the cost of people who are using the system > day-to-day. And isn't making it pleasant to use every day more important > than the minority of times you are telling somebody else how to use it? I probably should stated it differently. I dropped it during this round because they are _not_ needed to help the transition, but it is a possible additional feature. Let me try to explain the train of throught a bit better. People seem to expect "add -u" without any pathspec to work on the whole working tree structure even when you are in a subdirectory, similar to "git commit -a". We will be changing "add -u" in the longer term to do so. After the transition happens, people can easily say "add -u ." to limit it to the current subdirectory, and people can say "add -u ." even today to be explicit (which would help them transitioning). Before the transition, however, there is no pleasant way to cause "add -u" to add everything when you work in a subdirectory, short of saying: (cd $(git rev-parse --show-cdup)/. && git add -u) With ":/", we gain an easy way, "git add -u :/", to say "whole tree". That is the only thing this series does. Up to this part, I think we both agree are good thing. Now, imagine you were born in a world where we had the :/ magic from day one of git. Different commands "git add -u", "git grep", "git ls-files" without pathspec operate differently, and for some reason (e.g. usability, similarity to other people's corresponding command, or historical reasons) some of them operate only within the current subdirectory while others operate on the whole tree. The default behaviour might even be different between versions of git or user configuration. Because we assume that you already have both "." and ":/" to easily be explicit in that world, "teachers and helpers may have to scratch there head wasting their time" is no longer an issue. If you are teaching others, you ought to know about "." and ":/", and whether we add the configuration mechanism or not, you ought to know that you should be explicit to protect yourself from the differences between 1.7.X and 1.8.0 versions in the first place. So I agree that "costs teachers and helpers" is much less of an issue. You can certainly introduce configuration variables e.g. "addu.treewide", "grep.treewide", "lsfiles.treewide" (or even "core.treewide" to cover them all) to change the default behaviour for each user or each repository. The real question would become: if it is worth the maintenance cost of additional code to help users who want to avoid typing "." (or ":/") all the time in the environment they control. I don't know the answer to this question yet. A good new is that we had to conflate the discussion with "but there is no pleasant way to tell 'default to local' commands to work on the whole tree" justification for configuration variables before ":/". With ":/", that excuse will be gone and the discussion can be much more simplified. -- 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