Re: [PATCH 3/4] add -u: only show pathless 'add -u' warning when changes exist outside cwd
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Mar 19, 2013, 19:06 UTC
- Message-ID
- <20130319190624.GB3655@google.com>
- In-Reply-To
- <7v620nl99g.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 15 quoted lines
>> No time to review the code now. I thought about implementing something >> like that, but did not do it because I didn't want the change in the >> code to be too big. At some point, we'll have to remove the warning and >> it's easier with my version than with yours. But the "damage" to the >> code do not seem too big, so that's probably OK and will actually reduce >> the pain for some users. > > Getting these warnings is a *good* thing. > > You may happen to have no changed path outside the current directory > with this particular invocation of "git add -u", or you may do, or > you may not *even* remember if you touched the paths outside. > > Training your fingers to type "git add -u ." without having to even > think, is primarily to help the last case.
The problem is that these warnings are triggering way too often. It is like the story of the boy who cried "wolf": instead of training people to type "git add -u .", we are training them to ignore warnings.
I personally often find myself in the following situation:
$ cd repowithdeepsubdirs/third_party/git $ ... hack hack hack ... $ git add -u
The result is a pile of warning text that I cannot convince myself not to ignore because I already *knew* that the only changes present were under the cwd. The old and new "git add -u" behaviors always have the same effect in this case, so the warning is not relevant to me. So I find myself being trained to ignore the warning.
Presumably habitual Java hackers that do their work in a com/long/package/name subdirectory of the toplevel would find this even more annoying.
One important exception is that if "git add -u :/" is slow, users need to learn to run "git add -u ." to speed the operation up. But I think that is intuitive already. Running a full-tree diff which slows down the code that decides whether to print a warning is a good way to train people regarding how long to expect a plain "git add -u" to take.
Hoping that clarifies, Jonathan