On Sat, 13 Jan 2007, Carl Worth wrote:
> 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.
If nobody has been proposing that then it must not be a good direction
to go indeed. This is however not the case for 'add' handling both new
and existing files which I believe most people like.
> 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.
OK if that is what your grip is about let's fix the documentation then.
> 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).
No. The command set is sane. Many people like it, and it does the work
fine already, better than it used to.
You don't fix bad documentation by suiting the command set to it.
You fix the bad documentation instead.
So what about this:
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index cb081cd..96917d4 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -32,7 +32,7 @@ methods:
4. by using the -a switch with the 'commit' command to automatically "add"
changes from all known files i.e. files that have already been committed
- before, and perform the actual commit.
+ before, and/or "rm" missing known files, then perform the actual commit.
The gitlink:git-status[1] command can be used to obtain a
summary of what is included by any of the above for the next
Nicolas
-
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