0

I did a git commit but I included files I should not have.
Let's say commit 321232323232
That was the top commit. I did git reset --soft HEAD~1 and I can see my files as they were before I did the wrong commit and when I do a git log I don't see the bad commit but when I do git show bad_commit I can still see the changes!
Why is that?

Jim
  • 18,826
  • 34
  • 135
  • 254

2 Answers2

1

git reset --soft HEAD~1 The --soft option does not affect the index file or the current working tree, but leaves all the changed files "Changes to be committed". The "reset" you used copies the old head to .git/ORIG_HEAD, so you can redo the commit (with whatever new files you want) by starting with its log message.

You can take a look at the Git documentation for git-reset (git-scm.com/docs/git-reset) for more information.

Honesty
  • 150
  • 2
  • 11
  • My interest is that if I do a `git push` the bad commit does not get pushed – Jim Jun 30 '14 at 14:52
  • Then all you have to do is make sure that you've properly committed the files before the push (just redo the commit with the correct files). After this, you can push without any worries. – Honesty Jun 30 '14 at 14:55
  • So basically this `bad_commit` is somehow kept in history but is not part of the main trunk? – Jim Jun 30 '14 at 16:14
1

Even a git reset --hard HEAD~1 doesn't really destroy your commit; it just removes it from your known history. Because your commit is identified by its sha1, you can still find it with that same sha identifier.

If you use the git reflog command, you can see a history of positions of HEAD, including that commit you got rid of. It's a good way to find old commits that you didn't mean to delete.

Eventually (by default, after 90 days) Git will drop those old commits. If for some reason you want to drop them sooner, have a look at the git reflog documentation.

Ryan Lundy
  • 204,559
  • 37
  • 180
  • 211