Am Donnerstag, den 09.01.2020, 04:39 -0500 schrieb Jeff King: > You should be able to do: > > git checkout your-branch > git reset --hard <original> > > to go back to the state you were at (this is assuming you haven't > built > more commits on top, of course), and then repeat your steps. That > should > also clear out any breakage in the index, since "reset --hard" will > invalidate the cache-tree as necessary. > > If you need to find the commit id of that original commit, try > looking > in the reflog for your branch: git log -g your-branch Hi Peff, thanks that did work - but I had to "rm .git/index" before the hard reset to get those "deleted" ones removed from the staging area, after that I was able to use "git reset -- $files" and that was working like expected. Without deleting that index file I could run the hard reset but running "git status" afterwards insisted every time on this: On branch feature-2182 Changes to be committed: (use "git restore --staged <file>..." to unstage) deleted: docker-compose.gerrit.yml deleted: docker-compose.reverseproxy.yml deleted: docker-compose.yml deleted: docker-seccomp.json deleted: gradle.properties deleted: settings.gradle Those only vanished after deleting the index file. The "settings.gradle" is part of my changeset and listed in the "commit". But those other 5 files listed I had never touched in my commit - I don't know why they are in the staging area here - maybe some other edge case of the git restore bug - but just a "git hard --reset $hash" did not clear those. Torsten --
