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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Feb 28, 2011, 09:49 UTC
Message-ID: <4D6B6F97.8030409@drmicha.warpmail.net>
In-Reply-To: <vpqwrkkpkea.fsf@bauges.imag.fr>

Matthieu Moy venit, vidit, dixit 28.02.2011 10:40:

Show 31 quoted lines

> Michael J Gruber <git@drmicha.warpmail.net> 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.

No no, I said "add" would default to what "-u" does now (see below).

A user "starting to experiment with add" while have nothing in the index.

> 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

Since when do we care about them (as in "hg", not in "users", mind you...).

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

See, here!

Show 9 quoted lines

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

What in

> That would need a proper migration
> plan etc., and some thinking about -i/-o. Just brain-storming.

reads "proposal" to you?

Besides, current "git add ." is a really strange thing, doing more and less than "git add -u", mixing "update" with "track", but not completely. What is it even good for? ;)

(We could have an option for that, of course. Have I mentioned "radical"?)

Michael