Is the SHA-1 of commits calculated based only on the content of the tree?

Question

For the sake of an experiment, lets say your git log identifies the following commits

commit 16bc8486fb34cf9a6faf0f7df606ae72ad9ea438  // added          


        

Answer 1

The sha1 values for each of the file blobs will be identical in both cases if you have the same content (even if the filename is changed).

Likewise the sha1 values for the trees of the files blobs will be the same if they have the same filenames.

However at the very top we have the commit which will contain the unchanged link to the previous commit, the top tree, the author and commiter, but as KingCrunch said, the author and commiter date will be different, so the sha1 of the commit sha1 will be different.

You can make them the same if you deliberately set the author and commiter date using the environment variables so they are unchanged.

Answer 2

The SHA1 is calculated from the diff and all meta data from this commit (including the author and committer, the timestamp, and various other data).

For your second question, the data commit is still present but not part of any live branch anymore. Sometimes git will run a garbage collection where various deleted stuff will actually be removed. You will notice that once you manually run it using git gc that the unreferenced commit will be gone and not even be accessible with git show anymore.

Answer 3

Question 1: Because the hash is generated taking everything into account including the commit meta data (which itself contains the date and time).

Question 2: git log shows the log of the current branch. The commit 16bc8486 is not part of it. As far as I know (I'm not completely sure) the garbage collector will take it away sooner or later, if it finds it with nothing referencing it (git gc --help)..