Angelo Borsotti <angelo.borsotti@xxxxxxxxx> writes: > Hi > > I have displayed the contents of the commits with the command you indicate, > but they still look much the same: > > D:\gittest>git ls-tree -r --name-only 91ef45d > C1.java > C2.java > C3.java > C4.java > C5.java > > > D:\gittest>git ls-tree -r --name-only 8ec0c2f > C1.java > C2.java > C3.java > C4.java > C5.java > > I thought that in the second one I would see only the changed file. Git tracks contents. What it means is that you should stop thinking in terms of "changed files". Each commit (and its tree) represents a complete snapshot. Back when you created 8ec0c2f, did you or did you not have C1.java? You said you did not modify it, so I assume you did have it. As a commit is a complete snapshot of the contents, when you list the contents of 8ec0c2f, it should be included. To put it another way, if you "git checkout --detach 8ec0c2f" in order to go back to the state you were back when you created that commit, do you or do you not want to see C1.java and C2.java? In order to be able to reproduce the then-current state, of course you do want to see, and because each commit is a complete snapshot, you can see C1 and C2. "git add C1.java" is a way to make sure that, if you make a commit, the resulting "snapshot" includes the current contents stored in the C1.java file as you have on the filesystem at the time of issuing "git add" command. If you made or did not make changes to C1.java before running "git add C1.java" is immaterial. We may optimize out and make it a no-op if we know you did not make any changes, but it does not change the fact that the resulting commit will store, and more importantly, you will be able to recover, the then-current contents of C1.java out of that commit.
