Thus, when you ask Git "what happened to myfile", it uses the pathname myfile to look at the hash to look at the file contents, and then it can walk backwards to the previous commit (because commits are chained via parentage) and look at the pathname myfile again to look at that hash to look at those file contents: commit B -> list of names -> "myfile" -> hash -> contentsĬommit A -> list of names -> "myfile" -> hash -> contents Each pathname in a commit points to a hash which is also, by an incredible coincidence, the name (I'm simplifying) of the file where the contents are stored.
By definition, myfile has a different hash in the first commit (A) than it does in the second commit (B), because the hash of a file is an expression of its contents - only if myfile were identical in both commits would the hashes be the same (a clever trick for saving space in the repository, among other things).īut a commit also contains pathnames of its contents (I'm simplifying). You change its contents and you add it and you commit (call this commit B). You add it and you commit (call this commit A). Those files are represented in the commit as a list of pathnames each of which is tied to a hash which in turn is the name of a file containing some stuff.Īs a simple case, imagine a project where there is only one file under Git control, myfile. Git traffics solely in commits, which are snapshots of the entire state of the project, that is, all the files. The phrase "its sha1 hash changed" is nonsensical there is no "it" in the story. Git knows nothing whatever about "changed some file" it does not traffic in changes. Suppose we changed some file in our working directory and its sha1 hash changed completely and git has only hash from old file. This enables you to easily retrieve them if ever you deleted them by mistake (using -amend or when rushing into reset -hard too soon). They will be when the garbage collector pass, and only if they're both old enough and not referenced anywhere anymore.
What's really nice here is that those old objets aren't immediately deleted. using commit -amend), git simply discards the related objects and create brand new ones to replace them. When you modify something that already exists (i.e. So committing new stuff is just a matter of adding new objects. This eases the transition when valuesĪre changed to return standard int error codes over enum i40e_status. To prepare for removal of i40e_status, change the variablesįrom i40e_status to int.
Here's an example picked from Linux's kernel repository: $ git cat-file -p 7be099662200c7e In fact, commits are just a small text fragment that contains what we just explained above. You may check out the content of any object using cat-file command. These successive references to each previous commit are actually what forms history, like a huge linked list. Moreover, a commit also refers to its parent commit. This means that each commit references a tree object that is supposed to reflect the index's state at commit time, which tree, in turn, refers to all the file contents stored in index at this moment. Actually, there four types of objets : blobs, commits, trees and anotated tags.
0 kommentar(er)
