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

From: Chris Torek <chris.torek@gmail.com>
Date: Sep 17, 2025, 08:03 UTC
Message-ID: <CAPx1Gvdnz=PjF7viakFmYUSL72aQS83O9c8NWBCz_1Nt7z2V-Q@mail.gmail.com>
In-Reply-To: <c28bff47-04ef-4568-8dc3-add99f52209a@anselmschueler.com>

[resend as plain text]

On Tue, Sep 16, 2025 at 2:53 PM Anselm Schüler <mail@anselmschueler.com> 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.

Show 7 quoted lines

> 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