My goal is to revisit the original changes from an old buggy commit (which have since been reverted), but have those ancient changes in my worktree at the repo's HEAD since many things have changed, fix the problems, and submit a new better commit sans the problems.

A thousand commits ago (a month ago), I had committed a change.

A hundred commits ago (a week ago), someone discovered a subtle-but-unacceptable issue with the commit, so as to quickly unblock that person I reverted the commit (git revert hash ... worked like a charm).

A sprint has passed, and now at HEAD in my repo, I'd like to re-open the changes from the original commit that have since been reverted, so I can comb through the changes and figure out the root cause of the discovered problem.

What is a good way to "re-open" the commit from a thousand commits ago into my local worktree? (So git status would be modified in my worktree.)

Worse case scenario would just be to git checkout the old commit side-by-side in another repo and do a manual diff (e.g., vi -d current/foo.cpp ancient/foo.cpp) and copy over the differences by hand. Sounds tedious, and higher chance of manual error.

There will be a few collisions, but they'll be relatively trivial like fixed typos or whitespace changes.

I do not want to re-commit the ancient commit as-is, because it needs to be scrutinized and fixed.

CodePudding user response：

I'd suggest finding in your log history the hash for the revert commit, then with this <commit_hash> you can

git revert --no-commit <commitHash>
# or the shorter
git revert -n <commitHash>

...which will bring into your working tree the changes from the original commit without actually committing, which lets you test, write more code, and then commit when you're ready to.