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

[Carl Worth <cworth@cworth.org>]

[-- 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 --]