Andy Parkins [off-list ref] writes:
git-add with no parameters previously adds every modified file. This
patch instead makes git-add enter interactive mode.
...
It seemed a bit nasty to add content without explicit instructions to do
so.
Does anybody rely on the current behaviour?
It is nasty and I consider it a bug. It appears that it has
been like that since the days when it was still a shell script.
While I think nobody should drive 'git add' from script, the
behaviour to add everything when there is no explicit parameter
(or fall back to interactive for that matter) has a problem if
you say "some command | xargs git-add --" (you need "xargs -r"
to fix it, which is GNU).
Let's first have a patch to exit with a warning message (but
status 0) without doing anything when there is no explicit
paths.
Again, does anybody rely on the current behaviour?
On Tue, 19 Dec 2006, Junio C Hamano wrote:
Andy Parkins [off-list ref] writes:
quoted
git-add with no parameters previously adds every modified file. This
patch instead makes git-add enter interactive mode.
...
It seemed a bit nasty to add content without explicit instructions to do
so.
Does anybody rely on the current behaviour?
I don't know about "rely", but yes, it's what I normally do. When I import
a tar-ball, I'll just do
..untar..
cd result-x.y.z
git init-db
git add
git commit
and I don't usually use the "." at all, since it's unnecessary.
But hey, if it enters some interactive mode, maybe I can teach myself to
either just do "git add .", or if the interactive mode has a choice of "a"
for "all", then why not?
While I think nobody should drive 'git add' from script, the
behaviour to add everything when there is no explicit parameter
(or fall back to interactive for that matter) has a problem if
you say "some command | xargs git-add --" (you need "xargs -r"
to fix it, which is GNU).
That's a really good argument against the current behaviour of "git add",
so while I actually use it without any parameters, I will concur that we
should probably change it.