forgot to Reply All 💀



-------- Forwarded Message --------
Subject: 	Re: Why does git-status suggest different commands to unstage 
files depending on whether there is a commit yet or not?
Date: 	Tue, 16 Sep 2025 22:56:52 +0200
From: 	Anselm Schüler <redacted>
To: 	Junio C Hamano <redacted>



That makes sense, thank you.

I suppose this isn’t that interesting, but I find this unintuitive. If 
it were not for the suggestion in git-status on an empty repository, I 
would’ve assumed git-rm simply removes the file and “writes” that 
removal to the staged changes. This seems to be what y’all are 
describing. But with that suggestion, I was confused, because I assumed 
git-rm there would be equivalent in some sense to git-restore in a 
repository with commits.

Could git-restore be made to work anyway, by “imagining” a 
pre-initial-commit commit that has absolutely nothing in it?

On 16/09/2025 22:48, Junio C Hamano wrote:

Anselm Schüler [off-list ref] writes:

quoted

$ git status
[...]
No commits yet

Changes to be committed:
(use "git rm --cached <file>..." to unstage)
[...]

As this is a very initial commit, any file you are including would
only exist in the index and in the working tree files. The index is
where you prepare the contents of the commit you are going to
create, and "git rm --cached <file>" is the way to remove <file>
from there without losing or clobbering the <file> in the working
tree. As you do not have a commit yet, you wouldn't have anywhere
to "restore" from, would you?

quoted

After a commit has been made, git-status suggests using git-restore 
instead:

$ git status
[...]
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
[...]

Compared to the previous situation, you do have a commit, so you can
restore to the version in that commit. During the course of
development that led you to this state, you may have added <file> in
a commit way before the current commit, and you may have made
changes to the <file> multiple times in different commits before the
current commit. "git rm --cached <file>" would not be how you would
go back to the version in the current commit in such a situation, as
it would take you to the state _before_ you originally added that
file. You would "restore" the contents in the index to that of the
current commit (i.e. HEAD) to go back to the state.

So, isn't a short answer to the "why" question, "because that is
what you need to do", I guess?