On Sat, 13 Jan 2007 13:54:20 -0500 (EST), Nicolas Pitre wrote:
> The fact is that there is no strong reason why they shouldn't. But
> there are good reasons why they should. The most important one being
> that the user doesn't need to bother deciding which one of the two
> commands should be used in any given situation. And because a single
> command can cover two _technically_ different cases transparently is a
> pretty good reason for not imposing this technical issue to the user.
But that same reasoning could be extended to say there shouldn't be
separate "add" and "rm", because a single command can transparently
cover these two technically different cases transparently, (that would
be update-index without --add and --remove safety checks). But nobody
has been proposing that that would be a good direction to go.
So there are at least three cases one could identify for updating
content into the index:
1. Adding content for a path that didn't previously exist in the index
2. Updating content for a path that does already exist in the index
3. Removing a path and its content from the index
As things stand currently, git's providing a first-class operation
("git add") that provides (1) and (2) and another operation ("git rm")
for (3).
However, "commit -a" is implicitly performing operations from (2) and
(3).
So the documentation of "commit -a" being implemented with "add" just
plain doesn't make sense---and this is causing confusion.
I'd love to see _something_ get accepted to resolve that
confusion. What I was proposing was a command that did (1) and another
that did (2) or (3), (and "commit -a" could then be documented as
using this command).
But there are probably other ways to fix the problem.
-Carl
Attachment:
pgpfDY2FJL29T.pgp
Description: PGP signature