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

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

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".