git - 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 2nd file
commit 9188f9a25b045f130b08888bc3f638099fa7f212  // initial commit

After committing, .git/refs/heads/master points to 16bc8486fb34cf9a6faf0f7df606ae72ad9ea438.

Let's say, after this, i manually edit the .git/refs/heads/master file to point to 9188f9a25b045f130b08888bc3f638099fa7f212

At this point, git status recognizes that a new uncommitted file is in need of some attention. This is the same file my second commit took care of before.

If i do commit it .. git log now shows

commit b317f67686f9e6ab1eaabf47073b401d677205d5  // 2nd file committed for the 2nd time
commit 9188f9a25b045f130b08888bc3f638099fa7f212  // initial commit

Question 1:

You'll notice that SHA hashes are different between the very first time i committed a second file and now. Why is that? File's content did not change, it is still the same exact file.

Question 2

At this point, what happened to the original second commit? When i do git show 16bc8486, it shows this commit. It does not however show up in git log history.

Answer 1

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)..