Menu
Recently my main machine i use for development started overheating. I started to get 4 or 5 lockups per day. Everything freezes. All my projects are under version control using git.
I remember watching Linus' talk at Google saying git will ensure that the files are not corrupt. In my situation is it safe to assume that git will warn me if one of the source files gets corrupt.
OS is Mac OS X 10.4 file system is HFS+.
461
There is no central repository. Git has integrity, meaning each file is checked (summed) to be sure there was no bit loss during any file manipulation by git. Each snapshot (also called commit) has a unique identifier.
Git Has Integrity Everything in Git is checksummed before it is stored and is then referred to by that checksum. This means it's impossible to change the contents of any file or directory without Git knowing about it.
Use the git status command, to check the current state of the repository.
You can force Git to check the whole repository with git fsck. If a Git repository gets corrupted, you should get a new clone from a non-corrupted repository.
Under normal operation Git should check parts of the repository as they are read, so it might take longer to notice some corruption, but it will be noticed the first time that you try to access the corrupt data.
181
What Linus meant when he said that Git ensures the files are not corrupted, he was referring to the fact that when you refer to a particular commit (identified by its hash), you are guaranteed that it will always refer to the exact same repository state. If you and pull the linux kernel from Linus' tree, and he refers to some commit ae6bcd1..., there is nothing that you can do (even in your local repository) to ever make commit ae6bcd1... look any different from the commit Linus is looking at when he refers to it.
Furthermore, because a commit object contains references to (all of) its parent commit(s), when you refer to a commit you are guaranteeing its complete history in the DAG as well.
As far as file corruption, its sort of an independent issue; but without corrupting the actual blob objects (ie .git/objects/ob/ject_hashname) if one of your working tree files gets corrupted, you will be able to restore from a previous commit state or from an index/cached state.
You will never be able to corrupt a remote in this case unless you are doing forced pushes (which overwrite history on remotes), since push ensures the commit objects form a continuous history graph.
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
