Hi Matthiew, > Then the second commit does not "create" a new blob object for > file2.txt, because it has the same content as an existing one. But the > point is: you really don't care, or indeed, you care about sharing the > blob objects to save disk space. That is fine, and it is well documented. > It is predictible: give it twice the same inputs in the same conditions, > and it will yield the same output. Well, I have some difficulties to hit the return key while watching the system clock at the same time so as to make sure that the command is executed before the seconds change. So, it theory it would be predictable, but not in practice. Note that commands must be predictable for the user that writes them, i.e. the user must be able to figure out what the result is. Which is certainly not the case here. > > You still didn't tell us where the problem was. I described it few mails above. I wanted to create an orphan branch. The command to create it is git checkout --orphan. However, the branch is not actually created until a commit is done on it. Then I did such a commit (all this is placed in a script to be used by my developers), but if there are no changes, git commit does not create a new one. To force it to create a brand new one I added --allow-empty to it because the man page stated that it would bypass the check that prevents to make a new one. The I discovered that sometimes --allow-empty does not behave as expected. -Angelo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html