Re: Importing from tarballs; add, rm, update-index?

From: Nicolas Pitre <nico@cam.org>
Date: Jan 13, 2007, 20:29 UTC
Message-ID: <Pine.LNX.4.64.0701131503110.2577@xanadu.home>
In-Reply-To: <87wt3qwwm0.wl%cworth@cworth.org>

On Sat, 13 Jan 2007, Carl Worth wrote:

Show 13 quoted lines

> 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.

Show 18 quoted lines

> 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