Re: [RFC] A unique way to express "all" (vs "add vs "update") ?

From: Junio C Hamano <junkio@cox.net>
Date: Dec 15, 2006, 21:55 UTC
Message-ID: <7vzm9on7su.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <4582906A.7020204@op5.se>

Andreas Ericsson <ae@op5.se> writes:

Show 18 quoted lines

> Jerome Lovy wrote:
> ...
> But this isn't "commit" at all. It's "git add".
>
>>     (This would allow the typical usage "git commit -u ." which is
>>     barely longer than the current "git commit -a")
>>
>> For interface completeness, "git commit -u|--update <files>" could also
>> exist but would probably be of no use.
>>
>> To sum up, "all" would be consistently expressed with the <dir> syntax.
>> "git commit -a" would not mean "--all" anymore. Lastly, a distinction
>> would be made between "--add" and "--update":
>> - "git commit -add" would have the same semantics as "git add"
>
> This is bollocks. git commit should commit things. We'll be in some
> serious trouble if "git commit -a" stops working the way it has and
> starts just adding things to index.

I agree everything you said in your response to Jerome, except for one thing.

We might want to allow:

	$ git commit untracked.c tracked.c

to internally 'git add' untracked files while making the commit.

Currently you would get:

	$ git commit untracked.c tracked.c
        error: pathspec 'untracked.c' did not match any file(s) known to git.
        Did you forget to 'git add'?

which is usable, safe, and helpful, so changing it to automatically including it would not help the end user that much and one could argue that it removes the safety which is a bad idea.

So, let's not do this; sorry for the noise.