Matthieu Moy [off-list ref] writes:
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.
Squelching of the warning at the top-level is much less problematic
as it is much harder to forget if you are at the top level of the
working tree than forget if you touched paths outside the current
directory. "I know I am at the top, so I type 'git add -u' without
dot---why do you punish me with the warning?" is a much more valid
complaint.
Junio C Hamano wrote:
Matthieu Moy [off-list ref] writes:
quoted
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