Re: [PATCHv2 3/3] git-add: rename -u to -a

[Junio C Hamano <gitster@pobox.com>]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> Should -u now print warnings to help script writers migrate to -a? Or
> do we plan to keep hidden -u forever?

I'd rather not to apply 2 and 3 from this series for now, until we have a
more reasonable solution.  Yes, I said "add --add-tracked" _might_ be
worth considering, but that is in contrast to "add --tracked" which was
out of the question.

Like it or not, "add -u" has already been quite established, and the 'u'
stands for "update(d)" (i.e. "run update-index to the files updated in the
work tree"), which I think makes perfect sense.

I would suggest just keeping "add -u" as is.  As I said in the review in
the previous round, if Michael really wants to, it probably is Ok to give
"commit -a" a synonym "commit --update".

I further find that the verb form "--update" doesn't rhyme well as the
option name to select what classes of paths are operated on; it might make
sense to change the fully spelled version of the option for both commands
from "--update" to "--updated" while we are at it.  This would not bother
end users at all, as parse-options will complete "--update" typed by the
user or in scripts uniquely to "--updated" just fine.

Michael seems to be resisting against introducing "commit --update", and I
understand one reason is because "status -u" means something totally
different from "updated paths"; I am somewhat sympathetic to that fear.

But we started making "status" independent from being "commit --dry-run"
in 1.7.0 for a reason---it would be Ok if "status -u" means something
completely different from "commit -u", _as long as_ existing "commit -u"
does not make much sense.  I think that is the case here.

I don't think the distinction between "commit -a" vs "commit -A" is all
that bad.  When people talk about "all" files in the context of SCM, we
almost always think about already tracked paths, and other files do not
get into the picture unless you first "add" them (this is not limited to
git; even "svn commit" or "cvs commit" wouldn't touch untracked paths).
For this reason, it is not unexpected that the normal version of "all"
excludes untracked files, and you would need to ask for the unusual
version of "all" to include them (i.e. "commit -A" or "add -A") when
dealing with usual SCM commands.

The same argument however does _NOT_ hold for "add", as "add" (especially
in other SCM's context) is about making paths that haven't been tracked so
far into tracked ones; iow, it is natural to expect that "all" would mean
more than normal "all" (i.e. "all what are tracked") in the context of the
"add" command (and "add" command only).

IOW, renaming "add -u" to "add -a" and having "add -a" vs "add -A" is more
confusing than necessary, because of the nature of the word "add" that has
a connotation of affecting paths that have been untracked so far, and
keeping "add -u" and "add -A" distinct to avoid confusion is probably a
reasonable solution to avoid "which variant of 'all' are we talking about"
confusion.  This compromise unfortunately does not give us the uniformity
between '-a' vs '-A' applied to 'add' vs 'commit'.  That is why I would
suggest '-u' vs '-A' if we _really_ want to have such a uniformity between
two commands, i.e. not adding "add -a" but adding "commit -u".