Michael J Gruber [off-list ref] 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/
Matthieu Moy venit, vidit, dixit 28.02.2011 10:40:
Michael J Gruber [off-list ref] writes:
quoted
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 :-(
quoted
- "add" should be about tracked paths by default (default pathspec "."),
See, here!
quoted
- "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
On Mon, Feb 28, 2011 at 10:49, Michael J Gruber
[off-list ref] wrote:
No no, I said "add" would default to what "-u" does now (see below).
add -u adds untracked files. An explicit operation by the user. I hope
you really don't mean that just 'git add' would add all untracked
files? That would cause a terrible mess if someone just enters 'git
add' (which they could very well do in other situations than just
after 'git init', there are many casual git users out there.)
-Tor
Tor Arntsen venit, vidit, dixit 28.02.2011 11:01:
On Mon, Feb 28, 2011 at 10:49, Michael J Gruber
[off-list ref] wrote:
quoted
No no, I said "add" would default to what "-u" does now (see below).
add -u adds untracked files. An explicit operation by the user. I hope
you really don't mean that just 'git add' would add all untracked
files? That would cause a terrible mess if someone just enters 'git
add' (which they could very well do in other situations than just
after 'git init', there are many casual git users out there.)
Please, go read what (thread) you're replying to, then reply. I'm not
responsible for other people cutting my posts and turning around the
rest. (Also, you are wrong about "add -u".)
Michael