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

From: Jeff King <peff@peff.net>
Date: Jan 9, 2020, 09:39 UTC
Message-ID: <20200109093931.GA299671@coredump.intra.peff.net>
In-Reply-To: <654cc7a58cf6947f91478411dd6a3f7f3473bc67.camel@gmail.com>

On Wed, Jan 08, 2020 at 01:42:14PM +0100, Torsten Krah wrote:

> thanks for confirming those bugs and taking a look at my report itself
> even before I've put the small reproducer recipe.
> I don't need to take any other actions or create tickets somewhere else
> now to get those fixed, you're driving this from here, right?

Correct.

Show 7 quoted lines

> Another question - how can I fix my broken original branch where this
> bug did hit me which is in that "bogus" state now to get back to the
> "original" commit made so I can remove my unwanted files with "git
> reset HEAD <files>" instead of git-restore in the meantime (tried your
> rm .git/index variant but after that I had files which were already in
> the branch shown as unversioned after that, so that did not work very
> well for me)?

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

-Peff