Re: erratic behavior commit --allow-empty

From: Angelo Borsotti <angelo.borsotti@gmail.com>
Date: Oct 3, 2012, 07:35 UTC
Message-ID: <CAB9Jk9BczA0KjU2oKm=S_Ms6mqBFNHg8RO3xvb+PNEsMxQih+A@mail.gmail.com>
In-Reply-To: <506BE577.900@viscovery.net>

Hi Hannes,

>
> Perhaps you are confused by the fact that the commit you made first does
> not have a parent, either. But that is just a "side effect" that it
> happened to be the very first commit that you made after 'git init'.

Well, I know that, and this is why I added --allow-empty. The man page of git commit ("This option bypasses the safety, ..."). I thought that it would unconditionally create a brand new, commit.

> Your case does not demonstrate a bug in git.

The bug is that the git commit --allow-empty does a different action depending on whether the system clock has changed its seconds right before the command. This is a time-dependent behavior, and it is very harmful. Our applications must never behave differently depending on the time they are run or on the processor speed. It is an issue of correctness and robustness of software. To have a predictable behavior, i.e. to create a brand new commit with git commit --allow-empty, the command in a script must ALWAYS be preceded by a sleep 1 so as to make sure that the date and time it will use are for sure different from any other commits'. But then it would be a lot better to embed such a sleep in the command. If that is not possible, then the users must be warned in the man page that the command sometimes may not create a brand new commit, and that if the user instead wants it s/he should change something in the commit, like, e.g. the message.

>
> Why don't you use a different commit message to ensure that there is a
> difference between the commits?
>

This is what eventually I did to force the creation of a brand new commit.

-Angelo