Angelo Borsotti <angelo.borsotti@xxxxxxxxx> writes:
> "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.
It does create one; it just is the same one you already happen to have,
when you record the same state on top of the same history as the
same person at the same time.
> 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.
And how would it help what to insert a sleep for 1 second (or 1 year
for that matter)? As you said, it reads from the system clock, and
there are millions of systems in the world that have Git installed.
You may record the same state on top of the same history as the same
person on two different machines 5 minutes in wallclock time in
between doing so. These two machines may end up creating the same
commit because one of them had a clock skewed by 5 minutes.
What problem are you really trying to solve? You mentioned
importing from the foreign SCM, but in that case, you would be
building commits on top of other commits, and some commits may
not have any change recorded in them, i.e. you could validly
have (as always, time flows from left to right)
---o---o---o---o---A---B---C
where differences between A and B is nothing, and differences
between B and C is nothing. You may be a script that records these
commits in rapid succession.
When you create B and C, you may be recording the same state as the
same person with the same timestamp. *BUT* you are not recording
these two commits on top of the same history. B is done on top of
the history leading to A, but C is done on top of the history
leading to B. They will get different commit object name.
So what problem are you trying to solve?
You also did not seem to have read what I wrote, or deliberately
ignored it (in which case I am wasting even more time writing this,
so I'll stop).
This does not have anything to do with "--allow-empty"; removing
"the option" would not help anything, either. Run the following on
a fast-enough machine.
git init
>file
git add file
git commit -m initial
echo foo >file
git add file
git commit -a -m second
H1=$(git rev-parse HEAD)
git reset --soft HEAD^
git commit -a -m second
H2=$(git rev-parse HEAD)
if test "$H1" = "$H2"
then
echo I was quick enough
else
echo I was not quick enough
fi
--
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