From: Anselm Schüler <mail@anselmschueler.com>
Date: Tue, 16 Sep 2025 21:51:45 GMT
Subject: Fwd: Why does git-status suggest different commands to unstage files depending on whether there is a commit yet or not?
Message-ID: <c28bff47-04ef-4568-8dc3-add99f52209a@anselmschueler.com>
In-Reply-To: <8e1905c7-7744-444f-9a39-ca809edb6896@anselmschueler.com>

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 <mail@anselmschueler.com>
To: 	Junio C Hamano <gitster@pobox.com>



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 <mail@anselmschueler.com> writes:
>
>> $ 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?
>
>> 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?