Hi Junio, if I put on my head the implementor's hat, I would agree with you: that command after all behaves as implemented. However, if I put the user's hat I would reason differently. What I need are predictable commands, and that by all means is not. This because the time at which a command is executed is not predictable (more precisely, the statement in it that reads the system calendar). So, even if an implementor thinks that this behavior is reliable, a user thinks that it is not predictable. Actually, I called that command from within a script, and thus I could not count on it being executed within 1 second from the last commit. Read also the paragraph in the man page that describes it: "Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit. This option bypasses the safety, and is primarily for use by foreign SCM interface scripts." I cannot find any clue in it that lets me know that is does not create a commit if the time is within the same second as the other commit. My suggestion is either to include a sleep in the command so as to guarantee that a commit is created, or to remove the option. -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