Re: erratic behavior commit --allow-empty

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Oct 3, 2012, 07:12 UTC
Message-ID: <506BE577.900@viscovery.net>
In-Reply-To: <CAB9Jk9AgtNQfWDr31CWbXf2ag=11du-aruu-0+nOZ3KaaG9=og@mail.gmail.com>

Cc restored; please reply to all.

Am 10/3/2012 8:32, schrieb Angelo Borsotti:

Show 14 quoted lines

> Hi Hannes,
> 
> well, I thought I replied to your question:
> 
>    "What is the point in insisting that there is a *really*
>    new commit when the one commit that already existed has exactly the
>    content that you wanted?"
> 
> I wanted to create an orphan branch. I did it with a git checkout
> --orphan sources.
> This command alone does not create a branch; it needs a commit to be done on
> it, but a "real" one. If it is not a "real" one, the branch is
> created, but it is not an
> orphan one.

When you do 'git checkout --orphan sources', you request (nothing more and nothing less than) that the next commit you make on the new branch "sources" does not have a parent. But this is exactly what happens: The next commit you make does not have a parent.

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

IOW, the second commit that you made has all properties that you requested. (It just so happens that it is exactly identical to the first commit you made.) Your case does not demonstrate a bug in git.

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

-- Hannes