Am Dienstag, den 07.01.2020, 14:43 +0100 schrieb Torsten Krah: > Although restore --staged moved my unwanted files away from the > staging > area and "git status" told me that they are not "in" the commit the > commit itself did still include them. I can reproduce that (locally) at least: What does *not* work for me: git clone XX main cd main git fetch XX && git checkout FETCH_HEAD git checkout -b TEST git reset --soft HEAD~1 git restore --staged $FILES git status now lists $FILES as unstaged and they are not included in the staging area. git commit -> now $FILES are included in the commit (I would expect them not to be included - right?) and git status does list those still in the working area. What does work: git clone XX main cd main git fetch XX && git checkout FETCH_HEAD git checkout -b TEST git reset --soft HEAD~1 git reset HEAD $FILES git status now lists $FILES as unstaged and they are not included in the staging area. git commit produces a commit where $FILES are not included and they are still in the working area, unstaged - like expected. git status tells me this in the staging area part: Changes to be committed: (use "git restore --staged <file>..." to unstage) I did that and its not working (for me) - looks at least like a bug or I am doing something wrong and I am just too dumb at the moment to see my failure. Cheers Torsten PS: $FILES are files which are all "new" and first time added in the commit I want to modify with restore. PPS: The second problem with those staged deleted, unstageable, uncomittable files still persists in my copy of those branch (I can't reproduce that - still I have the repository in that state).
