On Tue, Apr 19, 2011 at 12:18:20PM -0700, Junio C Hamano wrote:
> Make "git add" to pretend as if "-A" is given when there is a pathspec on
> the command line. "git add" without any argument continues to be a no-op.
I like your proposed semantics much better. I remember many times early
on with git cursing the current behavior, until I finally trained myself
to do "git add -A".
> This might not be such a good idea, and I do not have a strong opinion
> for this change, but merely a weatherbaloon.
>
> Having "git add ." notice removals might lead to mistakes ("oh, I only
> meant to record additions, and didn't want to record the removals"), but
> at the same time, leaving it not notice removals would lead to mistakes
> by the other people ("I added, removed and edited different paths, but
> why only removals are ignored?").
I suspect most people will want the new semantics, because no matter
what your overall workflow, it is generally going to be some variant of:
1. hack hack hack
2. tell git about changes
And you don't really care about deletions versus modifications, you just
want them all added. But you probably _do_ care about additions versus
modififications, since step 1 often involves creating cruft that should
remain untracked (whereas it very rarely involves _deleting_ precious
files). And that's why we have "add -u", which should not go away.
My biggest worry would be people saying "eh? Add removes my files? That
makes no sense!" But we more or less already have that with "add -u",
and I think people have learned to accept that it is about "add the
current state to the index" and not "add files to git".
-Peff
--
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