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
--
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