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

From: Junio C Hamano <junkio@cox.net>
Date: Jan 12, 2007, 00:13 UTC
Message-ID: <7v1wm114rx.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87ac0pxgl2.wl%cworth@cworth.org>

Carl Worth <cworth@cworth.org> writes:

Show 13 quoted lines

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