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

[Junio C Hamano <junkio@cox.net>]

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.