3 ms·
No, each commit (or merge) is simply the SHA1 of the diff-patch. Thus adding the second file does create a diff, since the contents are not the same.
by anilgulecha 10y ago
No, each commit (or merge) is simply the SHA1 of the diff-patch.
Thus adding the second file does create a diff, since the contents are not the same.
- kinkrtyavimoodh 10y agoNo, a commit is not the SHA-1 of the diff. The fundamental object model of Git does not store diffs, it stores the actual state of the source tree as represented by a commit. For instance, here's a commit file [1]— $ git cat-file -p fdf4fc3 tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579 author Scott Chacon <schacon@gmail.com> 1243040974 -0700 committer Scott Chacon <schacon@gmail.com> 1243040974 -0700 first commit A commit object just points to the tree object (in turn, another SHA-1, this time of the complete directory listing) and other meta information such as author name etc. [1] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
- anilgulecha 10y agoCorrect -- I was being terse: the commit is a function of the changes going in (and metadata like time, authorship). Details: https://gist.github.com/masak/2415865 https://gist.github.com/masak/2415865
- 0x0 10y agoI'm not really talking about entire git commits, but just single files (blobs) within any commit/tree/repository
- chronial 10y agoThat is not correct and also not supported by your link. A git commit does not contain any changes. It is always a full sapshot of the repo state. To have any kind of concept of "change", you need two gït commits. Just like a simple text file.