This question already has an answer here:
On Git, say I mess up my commits, and I want to make the version 3 commits ago as the new version. If I do
git checkout xxxx, it creates a new branch and it seems like I can only merge it? Could I make this the new "master version"?
where F has exactly the same content as C
If I use
git revert xxxx instead, it seems like it definitely will have conflicts and I need to manually resolve it.
What I really want is just make the old commit at some point the new commit, regardless of what's in my working directory or the latest commit.
How would I go about doing this?
No, just git checkout XXXXX. rev~n means n revisions before rev.
The dot after HEAD~3 is important.
this works but I feel like there should be a more elegant way to do this.
with a large repo it takes awhile to delete all of the files and then check them all back out. I feel like git should have a way to revert to an old revision without having to delete everything. But that's just my opinion, this worked well for me and I didn't see a better way when I was looking for alternatives.
Is it possible to use a specific commit ID?
Hi thanks for the answer. But what if I don't want to do the hard reset since it's already pushed onto a public repository?
huggie Ah. Then you probably want to use the revert method
then git push -f to force push
Does this maintain commit "E" and create a new commit, "F"?
meetalexjohnson The revert method does; revert makes a new commit that is the opposite of the commit you specified, so they cancel out. The first revert would make F that's the opposite of E, and the second would make G that's the opposite of D, so you end up with the same code you had at C. That's why the second revert is HEAD~2 instead of HEAD~1 -- F is the head commit after the first one, so you need to go 2 back to refer to D
This causes rejection when pushing to origin.
This works for me. Pushing to origin wasn't a problem.
git cherry-pick C takes the changes introduced by C and applies them on top of E. This is not what the OP asked for. He wants to have the files in the exact state that they were in C, which git checkout provides.
Vote down. 1. the question explicitly asks for keeping older commits, so that might be a reason why other answers attempt to do that. 2. as you said, the commits might have been published and there's no need to introduce comments on what that means with rebasing.