Re: erratic behavior commit --allow-empty

From: Phil Hord <phil.hord@gmail.com>
Date: Oct 3, 2012, 12:59 UTC
Message-ID: <CABURp0pbX4Fk4sNWCicfF7Gm52-KTMBrasdi_XHnjtE2zmSBFg@mail.gmail.com>
In-Reply-To: <CAB9Jk9CSW0ObJtgsfSwjf+k438=V8i7dP0p+YUehqdh2Z0k6tA@mail.gmail.com>

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

Show 5 quoted lines

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

Perhaps the confusion arises from the the meaning of "the safety". In this case, the safety mechanism in place is to prevent you from creating a child commit which has the same "tree" contents (working directory) as the parent commit. It will not be the same commit because it has different parent(s) than its parent commit; but the tree (working directory) is the same and git normally prevents you from doing this because normally this is an accident, a mistake.

--allow-empty tells git you intend to do this and so it should bypass this "no changed files" safety mechanism. It is not a safety to prevent you creating a new commit with the exact same sha1; the safety is concerned only with the exact same "working directory" file contents.

Can you suggest a rewrite of this description which would make it more clear?

Phil