Ævar Arnfjörð Bjarmason [off-list ref] writes:
It's not so much about supporting scripting as exporting the
capabilities of the porcelain to the frontend utilities without
artificial limitations.
As a Porcelain, "git commit" has some leeway to enforce sensible policy on
the users, and "forbid commit that does not explain anything" is one such
policy. It is not generally a good idea to expose the full capabilities
of plumbing to Porcelain if it leads to bad user behaviour, and such
"artificial" limitations are safety features we do not want to remove.
Heya,
On Sun, Apr 4, 2010 at 21:11, Junio C Hamano [off-list ref] wrote:
As a Porcelain, "git commit" has some leeway to enforce sensible policy on
the users, and "forbid commit that does not explain anything" is one such
policy. It is not generally a good idea to expose the full capabilities
of plumbing to Porcelain if it leads to bad user behaviour, and such
"artificial" limitations are safety features we do not want to remove.
You contradict yourself:
commit 5241b6bfe2285a6da598a0348c37b77964035bc8
Author: Junio C Hamano [off-list ref]
Date: Mon Dec 3 00:03:10 2007 -0800
git-commit --allow-empty
It does not usually make sense to record a commit that has the exact
same tree as its sole parent commit and that is why git-commit prevents
you from making such a mistake, but when data from foreign scm is
involved, it is a different story. We are equipped to represent such an
(perhaps insane, perhaps by mistake, or perhaps done on purpose) empty
change, and it is better to represent it bypassing the safety valve for
native use.
This is primarily for use by foreign scm interface scripts.
Signed-off-by: Junio C Hamano [off-list ref]
--
Cheers,
Sverre Rabbelier