Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > A common workflow in large projects is to chdir into a subdirectory of > interest and only do work there: > > cd src > vi foo.c > make test > git add -u > git commit > > The upcoming change to 'git add -u' behavior would not affect such a > workflow: when the only changes present are in the current directory, > 'git add -u' will add all changes, and whether that happens via an > implicit "." or implicit ":/" parameter is an unimportant > implementation detail. > > The warning about use of 'git add -u' with no pathspec is annoying > because it serves no purpose in this case. So suppress the warning > unless there are changes outside the cwd that are not being added. That is a logical extension of the reason why we do not emit warnings when run at the top level. A user who has known about and is very much accustomed to the "current directory only" behaviour may run "git add -u/-A" always from the top in the current project she happens to be working on until Git 2.0 happens, and will not get any warnings. We are already robbing the chance to learn about and prepare for the upcoming change from her. And this patch makes it even more so. It does not make things fundamentally worse, but it makes it more likely to hurt such a user. The implemenation appears to run an extra diff_files() in addition to the one we already have to run in order to implement the "add -u" to collect modified/deleted paths. Is that the best we can do? I am wondering if we can special case the no-pathspec case to have add_files_to_cache() call underlying run_diff_files() without any pathspec, inspect the paths that are modified and/or deleted in the update_callback, add ones that are under the $prefix while noticing the ones outside as warning worthy events. -- 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