> You have it in one.
> Yes that is the reason that git computes the sha1 of the file's contents -
> it provides integrity, veracity and non-repudiation (the last one is still
> true though cryo-analysis is getting better, so sha1 is no longer
> recommended, and Git is looking at how to progress to newer crypto-hashes)
> Once Git has the sha1's of the files in a directory, it does the same
> again for the 'file' that lists the file names, mode bits and their
> content's sha1s, and ever onwards up the trees to the commit, which lists
> the sha1s of its parents.
> So it you have the sha1 of the tip of a branch, such as master, and you
> have a repo that holds that sha1, then you have the full crypto integrity
> that your copy (with all its history) is identical to that of the
> originators - your own Dali, Rembrant, Gogin, hanging in your hall... and
> it isn't even a replica, it's the real thing!
Dear Philip, Michael,
Thanks. It's true that checksums like SHA give a very signature of any
file. But where things start getting confusing (to me) is when I read *"**In
fact, Git stores everything in its database not by file name but by the
hash value of its contents.". *
This is from book Pro-Git.
So, if Git stores files using just their checksums then
a) how does it look up (or retrieve) a specific file in the database?
For example, if it wants to find a file in the data base then it takes
checksum and starts computing checking of every file in its database &
This looks pretty costly & rather unnecessary to me.
b) how does it get keep track file names that are required when it gives us
a working copy?
Thanks again ...
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.