git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Broken branch after git commit - tracked files in staging area can't be removed with restore --staged, or commit or stash

From
TKTorsten Krah <krah.tm@gmail.com>
Date
Jan 8, 2020, 10:02 UTC
Message-ID
<2423f8c0b91578c0faf7527b7d97b0e1e9666261.camel@gmail.com>
In-Reply-To
<20200108091119.GB87523@coredump.intra.peff.net>
Am Mittwoch, den 08.01.2020, 04:11 -0500 schrieb Jeff King:
Show 10 quoted lines
> That step seems wrong, and I can't reproduce it here. If "git status"
> lists the files as unstaged, then "git commit" should not be
> committing
> them. Can you show us a more complete example that we can run
> ourselves
> (i.e., that does not rely on whatever is in "main", and what is in
> $FILES)? Barring that, can you show us the output of the commands, as
> well as "git show FETCH_HEAD FETCH_HEAD~1"?
> 
> -Peff
Hi Jeff, I have a poc you can try:

cd /tmp mkdir testrepo cd testrepo touch TEST1 TEST2 git add -A git commit -m First touch TEST3 TEST4 git add -A git commit -m Second git reset --soft HEAD~1

git status
   Auf Branch master
   Zum Commit vorgemerkte Änderungen:
     (benutzen Sie "git restore --staged <Datei>..." zum Entfernen aus
   der Staging-Area)
   	neue Datei:     TEST3
   	neue Datei:     TEST4
git restore --staged TEST3
   [10:57:26][tkrah@torstenknbl:/tmp/testrepo]  (master) $ LC_ALL=C git
   status
   On branch master
   Changes to be committed:
     (use "git restore --staged <file>..." to unstage)
   	new file:   TEST4
   Untracked files:
     (use "git add <file>..." to include in what will be committed)
   	TEST3
git commit -m Second
   [master 5b62331] Second
    2 files changed, 0 insertions(+), 0
   deletions(-)
    create mode 100644 TEST3
    create mode 100644 TEST4

And now TEST3 is in the commit and what is even more "interesting" is the next one:

   [10:59:16][tkrah@torstenknbl:/tmp/testrepo]  (master) $ LC_ALL=C git
status
   On branch master
   Changes to be committed:
     (use "git restore --staged <file>..." to unstage)
   	deleted:    TEST3
   Untracked files:
     (use "git add <file>..." to include in what will be committed)
   	TEST3
TEST3 is unstaged and deleted now.
This seems wrong - or did I something wrong?
Cheers
Torsten
-- 
Mit freundlichen Grüßen / Best regards

Torsten Krah

mgm technology partners GmbH
Neumarkt 2
04109 Leipzig

Tel. +49 (341) 339 893-539
E-Mail Torsten.Krah@mgm-tp.com

Innovation Implemented.

Geschäftsführer / CEO: Hamarz Mehmanesh
Sitz der Gesellschaft / Registered office: München
Handelsregister/ Commercial register: AG München HRB 161298
USt-IdNr. / VAT ID: DE815309575
Previous: Jeff KingNext: Torsten Krah
Message 5 of 13 in “Broken branch after git commit - tracked files in staging area can't be removed with restore --staged, or commit or stash”
  1. Torsten KrahJan 7, 2020
  2. Torsten KrahJan 7, 2020
  3. Torsten KrahJan 7, 2020
  4. Jeff KingJan 8, 2020
  5. Torsten KrahJan 8, 2020
  6. Torsten KrahJan 8, 2020
  7. Jeff KingJan 8, 2020
  8. restore: invalidate cache-tree when removing entries with --stagedJeff King, Jan 8, 2020
  9. Junio C HamanoJan 8, 2020
  10. Dennis KaarsemakerFeb 5, 2020
  11. Torsten KrahJan 8, 2020
  12. Jeff KingJan 9, 2020
  13. Torsten KrahJan 9, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.