[resend as plain text]

On Tue, Sep 16, 2025 at 2:53 PM Anselm Schüler [off-list ref] 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