David Aguilar <davvid@xxxxxxxxx> writes: > Please enlighten me. > Are we really getting rid of it and replacing it with ":/"? > That syntax looks like a meh face.. just sayin' The current behavior is indeed replaced by "git add -u .", not ":/". > Unlike push.default, whose warning can be silenced with configuration, > git 1.x does not have a way to silence this warning without retraining > existing users. Yes, but push.default is really different: there is a config variable, and we want the behavior to be configurable. In the case of "git add", I don't think adding a configuration option would be the right thing. That would mean typing "git add -u" on an account which isn't yours will be unpredictable *forever*. OTOH, "git add -u :/" and "git add -u ." will behave predictibly on any version of Git that accepts them, past present or future (:/ was added in 1.7.6, a year and a half ago). > Another example... > > $ git grep 'stuff' :/ > > would it be too much to teach it to do: > > $ git grep -u 'stuff' "git grep" is out of the scope of this change. Yes, it is inconsistant with the rest of Git, but doesn't seem to surprise users as much as "git add -u" (for which the inconsistancy appears within the "add" command). I don't understand what you mean by "git grep -u". "git add -u" is a shortcut for "git add --update", and "git grep --update" wouldn't make sense to me. Do you mean we should add a "--full-tree" to "git grep"? That seems really overkill to me since we already have the :/ pathspec. > but in 2.0 that -u would be a no-op because "grep" will be full tree, no? No it won't. > I need to read the old discussions. > Can someone tell me the magic google search syntax they use to dig them up? See the discussion here: http://thread.gmane.org/gmane.comp.version-control.git/213988/focus=214106 (recursively, there's a pointer to an older discussion) > Would a better way be a method to make "git add -u" behave like 2.0 today? As I said, I think adding a configuration option that would remain after 2.0 would do more harm than good. But after thinking about it, I'm not against an option like a boolean add.use2dot0Behavior that would: * Right now, adopt the future behavior and kill the warning * From 2.0, kill the warning without changing the bevavior * When we stop warning, disapear. This, or the add.silence-pathless-warnings (which BTW should be spelled add.silencePathlessWarnings) would not harm as long as they are not advertized in the warning. What we don't want is dumb users reading half the message and apply the quickest receipe they find to kill the warning without thinking about the consequences. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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