Re: erratic behavior commit --allow-empty

From: PJ Weisberg <pj@irregularexpressions.net>
Date: Oct 3, 2012, 02:10 UTC
Message-ID: <CAJsNXTm9ADZv4SbabAR_WzGrZO8wDjvk+9Lsis0STHGo1EhqwQ@mail.gmail.com>
In-Reply-To: <CAB9Jk9D-eJ8goYx7LWqGcWcLgRDS8+qLZVUsvvJ+QOtryP9-zg@mail.gmail.com>

On Tue, Oct 2, 2012 at 2:56 PM, Angelo Borsotti <angelo.borsotti@gmail.com> wrote:

Show 13 quoted lines

> Hi Junio,
>
>> 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.
>>
>
> No, it does not create one: as you can see from the trace of the execution
> of my script, the sha of the commit is the same as that of the other,
> which means
> that in the .git/objects there is only one such commit object, and not two with
> the same sha. The meaning of the word "create" is to bring into being something
> that did not exist before. There is no "creation" if the object already exists.

It's also impossible to create two identical files in Git. If you try, you'll find that they both have the same SHA1, and thus are represented by the same object in .git/objects.

You have a script that creates two commits that are identical in every way. What practical difference does it make whether they're represented by one object or two?

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced.