Fwd: Why does git-status suggest different commands to unstage files depending on whether there is a commit yet or not?
- From
Anselm SchĂĽler <mail@anselmschueler.com>
- Date
- Sep 16, 2025, 21:51 UTC
- 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:
Show 38 quoted lines
> 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?