0

I accidentally committed a file to my git repo that was corrupt. The corruption happened when I was working on my laptop and the batteries died down. I didn't recognize at once that this ended up in a file which consisted of weird symbols only. However, I committed it to my repo.

Now I managed to revert to the previous non-corrupt version by using git revert HEAD^ and I have a non-corrupted version of the file. So far so good.

However, the log shows me that the corrupted file is still in the tree of my repo. My question now: Is this problematic, or can I forget about it? Is there a way to erase that corrupt commit/file out of the repo?

Josh Lee
  • 171,072
  • 38
  • 269
  • 275
absurd
  • 1,035
  • 3
  • 14
  • 35
  • In general, you should never destroy history. – SLaks Mar 24 '13 at 21:38
  • 3
    @SLaks: I disagree. On occasion, bad commits (like this one) make it in. If you haven't pushed them anywhere, it is perfectly reasonable to amend/rebase/destroy those commits. Cluttering history with corrupt files is not useful to anyone. – nneonneo Mar 24 '13 at 21:43
  • @nneonneo: Yes; that's why I said `In general`. – SLaks Mar 24 '13 at 21:50

4 Answers4

1

To roll back to a previous commit, use

git reset --hard <commit>

Assuming you are currently on a branch, this will set the branch head to the specified commit, and checkout your work tree to that commit. This will destroy any uncommitted changes!

If you later want to undo that, you can use git reflog to find the previous commit ID.

nneonneo
  • 171,345
  • 36
  • 312
  • 383
1

if you have not pushed the changes, git revert is probably not what you want. It makes a new commit that reverses the changes made.

Use git reset --hard <last good commit> to remove the bad commit. You can address this commit with a HEAD reference as you did, but that will not adjust the commits in the branch. If you reference the last known good commit with the branch name, such as git reset --hard <branch>~2 to reference 2 commits prior to the current one.

David Culp
  • 5,354
  • 3
  • 24
  • 32
  • 1
    If you use `--hard` it will reset the branch head, which does affect the commits visible in the branch. The commits are still in the repo, but they may be orphaned and will disappear if you `gc` or after they expire. – nneonneo Mar 24 '13 at 21:45
1

In general it is not a good idea to rewrite history. In public projects this may be the cause of weird corruption in threads if one developer managed to get the original tree before it was rewritten.

However for private branches you might want to rewrite history and hide mistakes before merging with the master.

Look at:

How do I push amended commit to the remote Git repository?

also here:

Git Tools - Rewriting History

Community
  • 1
  • 1
Eli Algranti
  • 8,707
  • 2
  • 42
  • 50
0

Please don't. git reset --mixed <good-commit> (--mixed is the default) keeps the workspace files as they are now, and resets the history git has stored to that <good-commit>. Then you can fix that up (correcting your corrupt file) and git commit to get to (presumably) the state you wanted in the first place.

vonbrand
  • 11,412
  • 8
  • 32
  • 52