Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > But just how useful is our default that "git add" is a no-op? I dont care very much myself, but if you consider "git add ." as a potentially destructive operation (discards changes that may be precious in the index), then it's good that "git add" is a no-op. Many beginners will try commands expecting to get a help message or a hint on how to use it when ran without argument (principle of least surprise) Like: $ ls file1 file2 => oh, so "ls" lists files. $ rm rm: missing operand Try `rm --help' for more information. => ok, so rm needs more operands A user typing "git add" just "to see what happens" may be disapointed to have all its files added. In particular since "git add" is silent by default, hence # let's see what happens ... $ git add $ # ok, nothing happened ... # continue hacking without noticing that a bunch of files have been added. Mercurial has taken the other way, making "hg add" add everything by default, and some users do complain: http://osdir.com/ml/version-control.mercurial.general/2007-08/msg00316.html If you change this for Git, you'll have people complaining about backward compatibility plus people complaining about least surprise :-( > - "add" should be about tracked paths by default (default pathspec "."), > > - "commit -a,--add <addopts>" be "add <addopts> && commit", and > > - "-A,--all pathspec" (default pathspec ".") be about tracked and > untracked paths (whether add or commit). Today, "git add ." adds new content in tracked files, and new files, but doesn't notice files deletions. Did I miss something, or is there no way to do that with your proposal? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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