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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthieu Moy venit, vidit, dixit 28.02.2011 10:40:
> 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.

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!

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]