From: Junio C Hamano <gitster@pobox.com>
To: "D. Ben Knoble" <ben.knoble@gmail.com>
Cc: "Anselm Schüler" <mail@anselmschueler.com>, git@vger.kernel.org
Subject: Re: Why does git-status suggest different commands to unstage files depending on whether there is a commit yet or not?
Date: Wed, 17 Sep 2025 05:12:52 -0700 [thread overview]
Message-ID: <xmqqqzw5i8fv.fsf@gitster.g> (raw)
In-Reply-To: <CALnO6CCz6dFX1Est0hhCbvaepBvG4+rpYQRQ2bP5vAQVmaY=OA@mail.gmail.com> (D. Ben Knoble's message of "Tue, 16 Sep 2025 16:52:17 -0400")
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
> ... " 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
Now I think about it more, I wonder if "restore --staged" is
misleading and confusing to new users?
When you teach "git restore" what would you tell them?
NAME
git-restore - Restore working tree files
is how "git restore --help" starts. It is primarily a tool to let
you repair messed up files in your working tree by copying out of a
known good version from somewhere, be it from the index or from an
existing commit.
But the instruction used to recover from unwanted "git add" to
update the index with modified contents does NOT want to destroy
your files in the working tree. You want to repair only the index
without touching your working tree files, because you added modified
contents that were not ready to be "staged". Hence "git restore" is
used with "--staged" option to tell it to do what it was *not*
primarily designed to do, i.e. only touch the index without doing
its usual "Restore working tree files" job.
But there is a lot more appropriate command whose primary focus is
about the index. "git reset <file>" would grab the contents for the
<file> in HEAD and replace the index entry for <file> with it, which
is exactly how you would move the "Changes to be committed" files to
"Changes not staged for commit" status.
So I think use of "git restore --staged" in the instruction is
wrong, and it should be replaced with "git reset" instead.
> (But the point about having nowhere to restore from stands!)
Yes, and the point about having nowhere to reset from stands for the
state on an unborn branch. That one needs "rm --cached".
next prev parent reply other threads:[~2025-09-17 12:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 20:29 Why does git-status suggest different commands to unstage files depending on whether there is a commit yet or not? Anselm Schüler
2025-09-16 20:34 ` Anselm Schüler
2025-09-16 20:48 ` Junio C Hamano
2025-09-16 20:52 ` D. Ben Knoble
2025-09-17 12:12 ` Junio C Hamano [this message]
2025-09-17 15:33 ` D. Ben Knoble
[not found] <8e1905c7-7744-444f-9a39-ca809edb6896@anselmschueler.com>
2025-09-16 21:51 ` Fwd: " Anselm Schüler
2025-09-17 8:03 ` Chris Torek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqqzw5i8fv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=mail@anselmschueler.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).