Re: [PATCH] add: allow users to silence Git 2.0 warnings about "add -u"

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

David Aguilar <davvid@gmail.com> 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/