Re: Why does git-status suggest different commands to unstage files depending on whether there is a commit yet or not?

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Sep 16, 2025, 20:52 UTC
Message-ID: <CALnO6CCz6dFX1Est0hhCbvaepBvG4+rpYQRQ2bP5vAQVmaY=OA@mail.gmail.com>
In-Reply-To: <5036f7d8-8ac9-4f50-99af-5a3a2d1a07fc@anselmschueler.com>

On Tue, Sep 16, 2025 at 4:36 PM Anselm Schüler <mail@anselmschueler.com> wrote:

Show 8 quoted lines

>
> After a new repository has been created, before a commit has been made,
> when files are staged, git-status suggests using git-rm to unstage
> files: $ git status [...] No commits yet Changes to be committed:   (use
> "git rm --cached <file>..." to unstage) [...] 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) [...] Why is this the case?

By following builtin/commit.c:cmd_status() to wt-status.c and searching for "rm --cached" (and then blaming), I found the following relevant commits:

- 80f537f79c (doc: promote "git restore", 2019-04-25): conversion from
reset to restore
- 4d4d5726ae (status: show worktree status of conflicted paths
separately, 2009-08-05): introduced the is_initial check

Unfortunately the latter does not appear to describe or justify the difference.

However, a quick test of the kind

    git init foo
    echo a > foo/a && git -C foo add a
    git -C foo restore --staged a

gives

    fatal: could not resolve HEAD

Contrary to Junio's mail about "where to restore from," the following does work in a non-unborn repo to move "newfile" from "untracked" to "staged" and back again:

    echo >newfile && git add newfile
    git restore --staged newfile

So we don't need "rm --cached" to

> remove <file>
> from there [the index] without losing or clobbering the <file> in the working
> tree

(But the point about having nowhere to restore from stands!)

-- 
D. Ben Knoble