Andreas Ericsson <ae@xxxxxx> writes:
> 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.
-
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