Re: erratic behavior commit --allow-empty

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