# Fwd: Why does git-status suggest different commands to unstage files depending on whether there is a commit yet or not? 3 messages from 2025-09-16 to 2025-09-18. Participants: Anselm Schüler, Chris Torek, Johannes Sixt. Thread: https://gitlist.dev/t/64157 ## Anselm Schüler, 2025-09-16 21:51 Subject: Fwd: Why does git-status suggest different commands to unstage files depending on whether there is a commit yet or not? Message-ID: URL: https://gitlist.dev/e/c28bff47-04ef-4568-8dc3-add99f52209a%40anselmschueler.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 To: Junio C Hamano 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 writes: > >> $ git status >> [...] >> No commits yet >> >> Changes to be committed: >> (use "git rm --cached ..." 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 " is the way to remove > from there without losing or clobbering the 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 ..." 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 in > a commit way before the current commit, and you may have made > changes to the multiple times in different commits before the > current commit. "git rm --cached " 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? ``` ## Chris Torek, 2025-09-17 08:03 Subject: Re: Why does git-status suggest different commands to unstage files depending on whether there is a commit yet or not? Message-ID: URL: https://gitlist.dev/e/CAPx1Gvdnz%3DPjF7viakFmYUSL72aQS83O9c8NWBCz_1Nt7z2V-Q%40mail.gmail.com In-Reply-To: ``` [resend as plain text] On Tue, Sep 16, 2025 at 2:53 PM Anselm Schüler wrote: > ... I would’ve assumed git-rm simply removes the file > and “writes” that removal to the staged changes. More precisely, it removes the file from the working tree and removes the index entry that would cause the index copy of the file to be in the next commit. > 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? Yes, and in fact a number of Git internal operations work this way, by pretending the commit before the first commit has as its tree the empty tree. If `git restore` did that here it would Just Work. (This is part of why the empty tree always seems to exist.) Whether this is a Good Idea, I leave to others to judge, as I'm too well steeped in Git internals to tell any more. :-) Chris ``` ## Johannes Sixt, 2025-09-18 06:56 Subject: Re: Fwd: Why does git-status suggest different commands to unstage files depending on whether there is a commit yet or not? Message-ID: <42250bbc-95f1-4f15-825e-66fbafb0b061@kdbg.org> URL: https://gitlist.dev/e/42250bbc-95f1-4f15-825e-66fbafb0b061%40kdbg.org In-Reply-To: ``` Am 16.09.25 um 23:51 schrieb Anselm Schüler: > [...] 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. You seem to think that `git rm` removes a *change*. This leads me to believe that you think of commits as a set of *changes*. But this is the wrong mental model. A commit is a complete state of the project, and the index ("stage") is the complete project state that is going into the next commit. `git rm` removes a file, not a change. -- Hannes ```