Jeff King <peff@xxxxxxxx> writes: > But we don't live in that world. We are making a transition, and so it > may be worth it to help: > > 1. People who want the new behavior _now_ without extra typing. > > 2. Placate people who say "...but I liked the old behavior better". > > I am in group (1). I don't know if people in group (2) need placating or > not, but I have grown to assume there will always be people to complain > about a change. :) Ok, first things first. Any new feature we add we would need to keep forever. I would rather not to see us having to maintain the default behaviour configuration variable forever into the future for these commands (not just add-u, but also grep, ls-files, ...). Now, having said that, we could vastly simplify things. I think the real cause of this confusion is because we have been dead-set assuming that we _have_ to change the default. The logic goes like this: - We will change the default, but we do not want to harm existing users; therefore - We need to introduce the variable to keep the old default not to harm existing users, but it would add to the uncertainty of the default when you do not know which version of git you are using. You now have to also worry about unknown configurations, so we need to train people to explicitly say '.' or ':/'; therefore - We need to issue warnings to train the user, but we do not want to show warnings to users who already learned the change is coming; therefore - We do need the configuration variable, and everybody needs to set it to squelch the warning. Otherwise "add -u" without any pathspec is too noisy to be usable. But I am not happy with the last step of the above deduction for two reasons. The configuration will only help people who have total control of the version of git they have on their boxes. They can say "Ok, I know what I want, and I know which default the version of git I installed on this box, so I set the variable and can forget about it forever, and keep typing 'git add -u' without any pathspec." But that would not work for people who need to work on multiple boxes, some of the boxes still running late 1.7.X while others running 1.8.0 or later, and the version of git they will be running is under sysadmin's control (your "a site that runs unknown version" example). These people need to train their fingers to be explicit when working in a subdirectory and running the command without a pathspec during the transition period anyway. It is a _good_ thing not to have any way to squelch the warning without being explicit in that sense, _if_ we are going to change the default. Another reason, which is worse, is that it would make it _harder_ to help migrating scripts, if the presense of the configuration variable squelched the warning. "Warn when run without pathspec from a subdirectory" would issue the warning every time until the invocation is changed to an explicit one, and your script that runs 'add -u' without pathspec will keep emitting the message until all such invocations are fixed. So let's step back a bit. How about we'd just add ':/' to make it equally easy to switch between "local only" vs "tree-wide" in 1.7.6 release, and be done with it. We don't change the default for any of the commands at all. No need to issue warnings because there won't be any backward imcompatible change. The users fingers do not need any re-training. There is no need to rewrite scripts, either. One good attribute of the combination of short-and-sweet ':/' and existing short-and-sweet '.' is that they make the default immaterial. Since more than a year ago, I've been saying that the ideal is to make the default not matter: http://thread.gmane.org/gmane.comp.version-control.git/133570/focus=133683 If the default does not matter, why change it? It just causes us more headaches for dubious gain, no? IIRC, I think the two reasons why we started discussing of "add -u" and friends were that (1) some commands default to whole-tree while others limit to $cwd --- inconsistency is bad; and (2) when the user wants to do a full tree "add -u", there is no way other than counting the current depth and typing "../" that many times. But when we looked at the current set of commands that limit them to the $cwd, we found that "add -u" was the only one that may make sense to switch the default, meaning that the "consistency" was not something we would even want to shoot for. For example, we want our "git grep -e pattern" to mimic "grep -r -e pattern .". And the second reason is going away, thanks to Michael and Duy's ':/'. -- 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