Removing files

Removing files

[David Kågedal]

I'm wondering what the best way to commit the removal of a file is.

Let's assume that I have a file "foo" in my tree, that I have removed
from my working tree (e.g. by using patch -E).

git status shows:

  $ git status
  # On branch refs/heads/messages
  # Changed but not added:
  #   (use "git add <file>..." to incrementally add content to commit)
  #
  #       deleted:    foo

Ok, so I try to follow the instructions in the message:

  $ git add foo
  fatal: pathspec 'foo' did not match any files

Ok, so that didn't work.  Let's try rm instead:

  $ git rm foo
  fatal: pathspec 'foo' did not match any files

Hm, something is wrong here.  But hey, there's a -f option to rm that
claims to prevent the "up-do-date check"

  $ git rm -f foo
  fatal: pathspec 'foo' did not match any files

Finally, I have to resort to using update-index.

  $ git update-index --remove foo
  fatal: pathspec 'foo' did not match any files

Since I believe that the idea is to move to an interface where you use
e.g. "git add" instead of explicitly mentioning the index, I think
this is bad.

What could be the correct command for this situation.  Some suggestions:

  $ git add foo
  $ git add --remove foo
  $ git rm foo
  $ git rm -f foo

-- 
David Kågedal

Re: Removing files

[Alex Riesen]

David Kågedal, Thu, Jan 11, 2007 21:10:20 +0100:
> I'm wondering what the best way to commit the removal of a file is.

git commit -a :)

Re: Removing files

[Seth Falcon]

fork0@t-online.de (Alex Riesen) writes:

> David Kågedal, Thu, Jan 11, 2007 21:10:20 +0100:
>> I'm wondering what the best way to commit the removal of a file is.
>
> git commit -a :)

:-(

I just ran into this very same thing.  I would vote for 'git rm'
and/or 'git add' doing the right thing here.  I'm probably missing the
reason they don't already.

Perhaps the doc should also highlight git's globbing, as opposed to
shell globbing as it is particularly useful when you have already
removed files and want to do:

git update-index --remove 'the-old-place/*.txt' 


+ seth

Re: Removing files

[Junio C Hamano]

David Kågedal <davidk@lysator.liu.se> writes:

> I'm wondering what the best way to commit the removal of a file is.

 $ rm -f foo
 $ git-commit -a

> git status shows:
>
>   $ git status
>   # On branch refs/heads/messages
>   # Changed but not added:
>   #   (use "git add <file>..." to incrementally add content to commit)
>   #
>   #       deleted:    foo

Suggesting "git add" to record the deletion feels insane.  Is
this what we still do?  I think there have been much work 
in this area recently so the wordings might have already fixed.

> Ok, so that didn't work.  Let's try rm instead:
>
>   $ git rm foo
>   fatal: pathspec 'foo' did not match any files
>

The above message is from an older version of git-rm, but the
one that will be in v1.5.0 is not any better.  It errs out with
"No such file or directory".  A workaround using today's tool is
to do "git rm --cached fo"

I think the right fix is to suggest "git add/rm" in status
output and make "git rm" not barf if the user has already
removed the file from the working tree.

        

Re: Removing files

[Eric Wong]

Junio C Hamano <junkio@cox.net> wrote:
> David Kågedal <davidk@lysator.liu.se> writes:
> 
> > I'm wondering what the best way to commit the removal of a file is.
> 
>  $ rm -f foo
>  $ git-commit -a
> 
> > git status shows:
> >
> >   $ git status
> >   # On branch refs/heads/messages
> >   # Changed but not added:
> >   #   (use "git add <file>..." to incrementally add content to commit)
> >   #
> >   #       deleted:    foo
> 
> Suggesting "git add" to record the deletion feels insane.  Is
> this what we still do?  I think there have been much work 
> in this area recently so the wordings might have already fixed.
> 
> > Ok, so that didn't work.  Let's try rm instead:
> >
> >   $ git rm foo
> >   fatal: pathspec 'foo' did not match any files
> >
> 
> The above message is from an older version of git-rm, but the
> one that will be in v1.5.0 is not any better.  It errs out with
> "No such file or directory".  A workaround using today's tool is
> to do "git rm --cached fo"
> 
> I think the right fix is to suggest "git add/rm" in status
> output and make "git rm" not barf if the user has already
> removed the file from the working tree.

Would having a command like 'hg addremove' make things easier?  I've
been using the below script since my early days of using git, but I
don't think I've ever published it.  If you want I can create a
patch against git.git

-----------------------------------------------------------------------
#!/bin/sh
# like the addremove command in mercurial

if test "x$1" = "x-h"
then
	echo "Usage: git-addrm [<path>]"
	exit 0
fi
SUBDIRECTORY_OK=1
. git-sh-setup || die "Not a git archive"

EXCLUDE_ARGS=--exclude-per-directory=.gitignore

if test -f "$GIT_DIR/info/exclude"
then
	EXCLUDE_ARGS="$EXCLUDE_ARGS --exclude-from=$GIT_DIR/info/exclude"
fi

set -e
git-ls-files -z --deleted $EXCLUDE_ARGS "$@"| \
	git-update-index --remove -z --stdin
git-ls-files -z --others $EXCLUDE_ARGS "$@" | \
	git-update-index --add -z --stdin
-----------------------------------------------------------------------

-- 
Eric Wong

Re: Removing files

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> I think the right fix is to suggest "git add/rm" in status
> output and make "git rm" not barf if the user has already
> removed the file from the working tree.

This does the latter.  A separate patch will do the former.

-- >8 --

[PATCH] git-rm: do not fail on already removed file.

Often the user would do "/bin/rm foo" before telling git, but
then want to tell git about it.  "git rm foo" however would fail
because it cannot unlink(2) foo.

Treat ENOENT error return from unlink(2) as if a successful
removal happened.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 builtin-rm.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/builtin-rm.c b/builtin-rm.c
index 5b078c4..d81f289 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -32,6 +32,10 @@ static int remove_file(const char *name)
 	char *slash;
 
 	ret = unlink(name);
+	if (ret && errno == ENOENT)
+		/* The user has removed it from the filesystem by hand */
+		ret = errno = 0;
+
 	if (!ret && (slash = strrchr(name, '/'))) {
 		char *n = xstrdup(name);
 		do {
@@ -204,7 +208,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
 		return 0;
 
 	/*
-	 * Then, unless we used "--cache", remove the filenames from
+	 * Then, unless we used "--cached", remove the filenames from
 	 * the workspace. If we fail to remove the first one, we
 	 * abort the "git rm" (but once we've successfully removed
 	 * any file at all, we'll go ahead and commit to it all:
-- 
1.4.4.4.gb8a1

[PATCH] git-status: wording update to deal with deleted files.

[Junio C Hamano]

If you do:

	$ /bin/rm foo
	$ git status

we used to say "git add ... to add content to commit".  But
suggsting "git add" to record the deletion of a file is simply
insane.

So this rewords various things:

 - The section header is the old "Changed but not updated",
   instead of "Changed but not added";

 - Suggestion is "git add ... to update what will be committed",
   instead of "... to add content to commit";

 - If there are removed paths, the above suggestion becomes "git
   add/rm ... to update what will be committed";

 - For untracked files, the suggestion is "git add ... to
   include in what will be committed".

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 * This needs the previous "git rm" update to make sense.
   Currently "/bin/rm foo ; git rm foo" would fail because the
   latter cannot remove foo (it gets "No such file or
   directory").

 wt-status.c |   19 ++++++++++++++++---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 1dc2fdc..a849951 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -15,7 +15,13 @@ static char wt_status_colors[][COLOR_MAXLEN] = {
 	"\033[31m", /* WT_STATUS_CHANGED: red */
 	"\033[31m", /* WT_STATUS_UNTRACKED: red */
 };
-static const char* use_add_msg = "use \"git add <file>...\" to incrementally add content to commit";
+
+static const char use_add_msg[] =
+"use \"git add <file>...\" to update what will be committed";
+static const char use_add_rm_msg[] =
+"use \"git add/rm <file>...\" to update what will be committed";
+static const char use_add_to_include_msg[] =
+"use \"git add <file>...\" to include in what will be committed";
 
 static int parse_status_slot(const char *var, int offset)
 {
@@ -177,8 +183,14 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
 	struct wt_status *s = data;
 	int i;
 	if (q->nr) {
+		const char *msg = use_add_msg;
 		s->workdir_dirty = 1;
-		wt_status_print_header("Changed but not added", use_add_msg);
+		for (i = 0; i < q->nr; i++)
+			if (q->queue[i]->status == DIFF_STATUS_DELETED) {
+				msg = use_add_rm_msg;
+				break;
+			}
+		wt_status_print_header("Changed but not updated", msg);
 	}
 	for (i = 0; i < q->nr; i++)
 		wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
@@ -265,7 +277,8 @@ static void wt_status_print_untracked(struct wt_status *s)
 		}
 		if (!shown_header) {
 			s->workdir_untracked = 1;
-			wt_status_print_header("Untracked files", use_add_msg);
+			wt_status_print_header("Untracked files",
+					       use_add_to_include_msg);
 			shown_header = 1;
 		}
 		color_printf(color(WT_STATUS_HEADER), "#\t");
-- 
1.4.4.4.gb8a1

Re: [PATCH] git-status: wording update to deal with deleted files.

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]

All very good stuff Junio, thanks.

In light of the big long message I just wrote, let me comment on the
changes you just made here.

On Thu, 11 Jan 2007 15:37:41 -0800, Junio C Hamano wrote:
> we used to say "git add ... to add content to commit".  But
> suggsting "git add" to record the deletion of a file is simply
> insane.

I'm very happy to hear you agree that would be insane.

>  - The section header is the old "Changed but not updated",
>    instead of "Changed but not added";

Again, not only deletion, but another place where "add" doesn't work
universally. As I mentioned in my other thread, the experiment in
using "add" as a first-class porcelain for all index updating just
doesn't work everywhere.

The caution I would point out here is that we are now introducing a
term ("update") into the output-side of git's user-interface, but that
there's no corresponding "update" on the input side, (at least as far
as porcelain is concerned). So conceptually, the user can be left
with, "hmm... it's not updated, but how the heck do I update it?".

>  - Suggestion is "git add ... to update what will be committed",
>    instead of "... to add content to commit";
>
>  - If there are removed paths, the above suggestion becomes "git
>    add/rm ... to update what will be committed";

Here now we do start providing the user with some mechanisms for
"update". Sometimes we suggest using "add" to update, and sometimes we
suggest using "add" or "rm" to update. But as you yourself have
pointed out, you consider "rm" a totally pointless command.

Wouldn't git be simpler if it only provided one porcelain command for
updating content into the index? I proposed "stage" in my preceding
email---but I don't care what the actual term used is. But it should
definitely be a term that's consistent with the terms that git-status
uses to describe the state of these files.

>  - For untracked files, the suggestion is "git add ... to
>    include in what will be committed".

And here is where git-status points out that "git add" has another use
that's conceptually distinct from updating content. I think that
distinction should be made more clear by "git add" being a separate
command from whatever the porcelain for "update content into the
index" becomes.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] git-status: wording update to deal with deleted files.

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> ... So conceptually, the user can be left
> with, "hmm... it's not updated, but how the heck do I update it?".
>
>>  - Suggestion is "git add ... to update what will be committed",
>>    instead of "... to add content to commit";
>>
>>  - If there are removed paths, the above suggestion becomes "git
>>    add/rm ... to update what will be committed";
>
> Here now we do start providing the user with some mechanisms for
> "update". Sometimes we suggest using "add" to update, and sometimes we
> suggest using "add" or "rm" to update. But as you yourself have
> pointed out, you consider "rm" a totally pointless command.

You are twisting my words ;-).

"rm" is pointless for a workflow that always uses "commit -a".
In the same sense, the three categorization "git-status" gives
is pointless -- "changed but not updated" class does not have
any significance if you always do "commit -a".

But that is not the only workflow we encourage.

I do encourage "commit -a" or "commit after update-index" and
frown upon but tolerate "commit <paths>..." --- all of the above
is in line with this world view.   And the categorization and
suggestions are about the latter: "commit after update-index".

Then the issue is how to expose update-index to the end users.
"add" is about adding the content.  What's unfortunate is that
adding a file as zero-length content is still different from
removing it.

Honestly, removing is so different from the norm that I do not
see major inconsistency nor inconvenience, practically nor in
philosophy, to have two separate Porcelain-ish commands, add and
rm, to perform content additions and removal.

Re: [PATCH] git-status: wording update to deal with deleted files.

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]

On Thu, 11 Jan 2007 16:13:06 -0800, Junio C Hamano wrote:
> You are twisting my words ;-).

I apologize. I really didn't intend to twist any words. What I was
remembering was a sentence like the following:

	From: Junio C Hamano <junkio@cox.net>
	Message-ID: <7vfyatt8di.fsf@assigned-by-dhcp.cox.net>
	Subject: Re: How to commit removed file?
	Date: Tue, 02 Jan 2007 13:40:41 -0800
	...
	Personally I never saw the point of having "git rm".  Maybe we
	should remove it to prevent this confusion from happening.

What I'll describe below would actually allow us to drop git-rm if we
really wanted to, (but I don't think it's important to do that, nor
that we even should). That's just an almost accidental side effect of
what I'm describing.

> But that is not the only workflow we encourage.
>
> I do encourage "commit -a" or "commit after update-index" and
> frown upon but tolerate "commit <paths>..." --- all of the above
> is in line with this world view.

OK, so let's use these two different workflows and look at what we're
providing. (Personally, I also like to think about only two different
workflows, but I see "commit <paths>..." as just doing a
file-boundary-based subset of "commit -a").

Currently, the necessary, porcelain, "commit preparing" commands for
each workflow are:

commit after update-index
-------------------------
git add: add content for new files, modified files
git rm: mark files to be removed

commit -a
---------
git add: mark new files to be committed

> Then the issue is how to expose update-index to the end users.
> "add" is about adding the content.  What's unfortunate is that
> adding a file as zero-length content is still different from
> removing it.

But fortunately the distinction between a zero-length file that exists
and a file that does not exist is quite evident in the working
tree. So it would still be a very well-defined thing to have a command
for "update content" that could update whatever content a file has
into the index (even zero-length content) if the file exists in the
working tree, or remove the path from the index if the file does not
exist.

I agree that "add" would be an insane name for this command. The best
proposal I've been able to make for this command is "stage". The only
other thing I can think of that uses accepted terminology from git
would be "update", but I think that would be a very bad choice, (since
certain other version control systems use "update" to describe an
operation much more like git's "pull").

So if we had this "stage" command, (and assuming it staged content for
new files), then look what happens to the list of preparatory commands
needed for each workflow:

commit after stage
------------------
git stage: stage content for new, modified, or removed files

commit -a
---------
git add: mark new files to be committed

Compare that to the above description. Isn't it beautiful from a
conceptual point-of-view? The "git rm" command isn't needed at all,
(though we could certainly still provide it). And now the "git add"
command only has one conceptual use, for (of all thing!) adding new
files, not updating content for files that have been modified.

> Honestly, removing is so different from the norm that I do not
> see major inconsistency nor inconvenience, practically nor in
> philosophy, to have two separate Porcelain-ish commands, add and
> rm, to perform content additions and removal.

I don't have a problem with it either. I'm not trying to make an
argument based on why git-rm should be removed. It can live around all
it wants, but I think there's conceptual simplification in this model,
(which can only help to make git easier to learn).

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] git-status: wording update to deal with deleted files.

[Jakub Narebski]

Carl Worth wrote:

> commit after stage
> ------------------
> git stage: stage content for new, modified, or removed files
> 
> commit -a
> ---------
> git add: mark new files to be committed
> 
> Compare that to the above description. Isn't it beautiful from a
> conceptual point-of-view? The "git rm" command isn't needed at all,
> (though we could certainly still provide it). And now the "git add"
> command only has one conceptual use, for (of all thing!) adding new
> files, not updating content for files that have been modified.

Without "git rm" (or "git update-index --force-remove") you cannot
make file to be untracked by git, i.e. remove it from the files
tracked by git but not remove it from directory.

With current version of git-rm (modulo bugs), if you do "git rm <file>"
the file would be removed from index, and if recoverable from working
directory. Without git-rm you would have to use plumbing to remove it from
index but preserve changes.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] git-status: wording update to deal with deleted files.

[Jeff King]

On Thu, Jan 11, 2007 at 03:37:41PM -0800, Junio C Hamano wrote:

>  - The section header is the old "Changed but not updated",
>    instead of "Changed but not added";

Isn't that the original wording that we recently got rid of? I think
it's a bit confusing, given that "changed" and "updated" really mean the
same thing (we tend to use 'updated' only to refer to the index, but new
users don't know that). How about "Changed but not marked for commit"?
Or even "Files with changes that are not marked for commit" (which is
longer, but more precise).

Maybe it would be clearer to split the section (and only show those
sections which are applicable):

  Files with changes that have are not marked for commit:
    (use "git add <file>" to mark changes)

  Files that have been removed but not marked for commit:
    (use "git rm <file>" to mark for commit)

  Files that exist but have not been marked for commit:
    (use "git add <file>" to mark for commit)

The latter being the current untracked files. And potentially even:

  Files that have merge conflicts:
    (use "git add <file>" to mark as resolved)

And yet another option would be to individually mark each file:
  #  deleted: foo  (use "git rm" to mark for deletion)
but I think that is probably too verbose.

Anyway, please consider my first wording change, if not the more radical
splitting.

-Peff

Re: [PATCH] git-status: wording update to deal with deleted files.

[Juergen Ruehle]

Junio C Hamano writes:
 > If you do:
 > 
 > 	$ /bin/rm foo
 > 	$ git status
 > 
 > we used to say "git add ... to add content to commit".  But
 > suggsting "git add" to record the deletion of a file is simply
 > insane.
 > 
 > So this rewords various things:
 > 
 >  - The section header is the old "Changed but not updated",
 >    instead of "Changed but not added";
 > 
 >  - Suggestion is "git add ... to update what will be committed",
 >    instead of "... to add content to commit";
 > 
 >  - If there are removed paths, the above suggestion becomes "git
 >    add/rm ... to update what will be committed";
 > 
 >  - For untracked files, the suggestion is "git add ... to
 >    include in what will be committed".
 > 
 > Signed-off-by: Junio C Hamano <junkio@cox.net>

I should have beaten you to it, since Michael had already noticed that
on wednesday, but I was too busy. Thanks.

Re: Removing files

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 7746 bytes --]

On Thu, 11 Jan 2007 21:10:20 +0100, David Kågedal wrote:
> Let's assume that I have a file "foo" in my tree, that I have removed
> from my working tree (e.g. by using patch -E).

Thanks for the example, David. I think this points out several
problems with the current state of git.

>   # Changed but not added:
>   #   (use "git add <file>..." to incrementally add content to commit)
>   #
>   #       deleted:    foo
> 
> Ok, so I try to follow the instructions in the message:

Clearly "git add" is the wrong thing to recommend here, (in that it
currently doesn't update the index for a removed file). I think this
is a bug in git-status.

I also believe it would be incorrect to "fix" git-add to make it
remove files as well. Having a command named "add" whose
functionality could be to do the opposite of the meaning of that
command would be horribly confusing, (and not an improvement in the
usability or learnability of git).

>   $ git rm foo
>   fatal: pathspec 'foo' did not match any files

I think that's just a bug in git-rm and should be fixed.

> What could be the correct command for this situation.  Some suggestions:
> 
>   $ git add foo
>   $ git add --remove foo

As I said above, I think making "add" perform removal, (which is the
opposite of what "add" means) would be a very bad idea.

>   $ git rm foo
>   $ git rm -f foo

I think either of the above should be fixed to work. The "safety
check" here is an attempt to catch typos, right? Shouldn't that be
checking for the existence of the path in the index rather than in the
working tree?

There are also two other possible commands here:

$ git commit file

On the list someone recently pointed out that this didn't work for
them (after removing a file). I had thought the conclusion was that
Junio wasn't interested in doing the work to make "index skipping"
work for this case. But maybe someone else did the work already,
because this did work for me when I tested now. Did I just get lucky?
Or is this officially supported now? (I'm quite happy to see this
working as otherwise we'd be left with only "commit -a" as a
pure-porcelain way of removing files---see below.)

$ git commit -a

This was already mentioned in a separate reply. This works, but there
are a couple of problems if this were the only supported way to remove
a file:

1. It doesn't allow for a "staged" file removal, (that is removing a
   file while allowing other dirty changes to remain in the working
   tree).

2. The fact that "commit -a" commits file removal is not documented at
   all. This was pointed out to me recently by a cairo contributor who
   was quite tripped up by this aspect of "commit -a".

   What the "commit -a" documentation says is:

       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.

   And as already discussed above, "add" doesn't actually updating a
   file removal into the index. And I think it would be a mistake to
   extend "add" to do removal as well, (at that point "add" would
   become little more than a synonym for update-index without the
   --add and --rm safety checks).

So what's the fix for the "commit -a" documentation? One approach is
to add more language about file removal to the description of "commit
-a". The wording proposed by Jonathan Watt is:

       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),
          automatically remove all known files that have been removed from the working
          tree, and perform the actual commit.

That's perhaps functional, but it's getting to be a lot of language to
have to grasp for new users. The goal of the new first-class-add was
to be able to simplify the documentation of things like this. I think
that's a failed experiment.

I'd much rather see the documentation for git-commit present a list
something like the following:

  Use git commit to record changes into the repository along with a
  log message describing the changes. New files (or directories) must
  be made known to git with "git add" before they can be committed.

  The changes to be committed are identified with one of three
  different forms of the git commit command:

  1. git commit

	Without any specific file names mentioned (and without the -a
	option), commit changes from content that has been "staged"
	for this commit. Content can be staged with the "git add" or
	"git rm" commands.

  2. git commit paths...

	With a list of file (or directory) paths, commit changes from
	the working-tree content of all named paths, (remember that
	"git add" must be used before committing any new files).

  3. git commit -a

	Commit the working-tree content of all files known to git,
	(remember that "git add" must be used before committing any
	new files)

  Note that what git commits is "working-tree content" that means that
  committing file a file deletion is as simple as removing the file
  from the working tree and then using "commit -a" or "commit file" to
  commit that removal.

I've written that in a way that it should be usable as documentation
without any changes to how git currently works, (I think---let me know
if I got any of it wrong).

But I would still like to point out some things that could be
improved. First, the "(remember that 'git add'...)" phrases are quite
redundant and should really be removed. I included them here only to
point out that the way that "git add" with "commit paths..." and
"commit -a" is really fundamentally different than "git add" used for
staging with git-commit (form (1) without paths or -a).

I think that difference should be fully recognized, and that git could
be made easier to learn if it were. Specifically, I think a "git
stage" command, (a "porcelain" version of update-index) would fit into
the description of form (1) quite nicely.

Also, (and especially if the "remember" phrases are removed), note
that the three different commit commands are written in
reverse-simplicity order. That is, "commit -a", the form with the
shortest explanation (and the fewest necessary concepts), comes
last. That's also not so nice for learning. So, I think the order of
the descriptions should be reversed, (with this style of explanation
for "commit -a", there's no need to base it on an understanding of a
staged commit first).

So, what I'd like to see, (but would require the addition of "git
stage" and a slight philosophical switch in the consensus for how git
should be taught), would be:

    git commit -a

	Commit the working-tree content of all files known to git.

    git commit paths...

	Commit changes from the working-tree content of the specified
	paths.

    git commit

	Commit changes from all content that has been staged with
	"git stage".

This approach, (separating "stage" for staging into the index from
"add" for adding new paths), would also allow for "add" to be changed
to not also stage the content into the index.

I really like the simplicity of explanation that this model
provides. And I'd love to hear any feedback that anybody has about it.

-Carl

PS. And look! I even resisted the next step which would be to
recognize that the simplest-to-explain and most-common-to-use form
should have the simplest command-line syntax. That is, I didn't
suggest command-lines of:

    git commit
	...
    git commit paths...
	...
    git commit -s|--staged
	...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Removing files

[Jeff King]

On Thu, Jan 11, 2007 at 03:41:05PM -0800, Carl Worth wrote:

>     git commit -a
> 
> 	Commit the working-tree content of all files known to git.
> 
>     git commit paths...
> 
> 	Commit changes from the working-tree content of the specified
> 	paths.
> 
>     git commit
> 
> 	Commit changes from all content that has been staged with
> 	"git stage".
> 
[...]
> I really like the simplicity of explanation that this model
> provides. And I'd love to hear any feedback that anybody has about it.

I think this is a very easy way of explaining it in the documentation.
But what do you think 'git status' should say about changed files?
Currently we make recommendations about how to stage the various files.
It would certainly be simpler to recommend 'git commit -a' for changes,
but that feels wrong.

-Peff