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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 22, 2013, 17:30 UTC
Message-ID: <7v621ks1cf.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqd2vssnh7.fsf@grenoble-inp.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 5 quoted lines

> 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*.

Exactly.

Show 9 quoted lines

>> $ 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).

It is consistent with "grep", and the reason "git grep" behaves that way is because consistency with "grep" matters more. I do not think it is going to change.

Another is "clean", which I do not personally care too deeply about; it being a destructive operation that is only used interactively and occasionally), the current behaviour to limit it to the cwd is much more sensible than making it go and touch parts of the tree that is unrelated to cwd.

> I don't understand what you mean by "git grep -u".

I think he meant to add "git grep --full-tree" or something, and I do not think it is going to happen when we have ":/" magic pathspec.

Show 9 quoted lines

> 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.

It is marginally better than David's "set once without thinking because I read it on stackoverflow without fully understanding the ramifications, and forget about it only to suffer when Git 2.0 happens" configuration variable, but by not much. You can easily imagine

	Q. Help, Git 1.8.2 is giving me this warning. What to do?
	A. Set this configuration variable. period.

and many users setting it without realizing that they are making the operation tree-wide at the same time. We'd want to see this answer instead:

	A. Say "git add -u ."; you want to add changed paths in the
 	   current directory.

Another problem with use2dot0 configuration is that it would invite people to imagine that setting it to false will keep the old behaviour forever, which is against what you set out to do with the patch under discussion.