On 2009 Mar 7, at 22:14, Junio C Hamano wrote:
UNEVEN TREATMENT OF EMPTY CHANGES
fetch, push, bundle
They just transfer an existing history from one place to another
without
modifying, so it is unfortunately true that they preserve such a
broken
history with empty commits.
'format-patch', 'send-email', 'apply', 'am', 'rebase' (automatic,
non-fast-forward; and --interactive).
These are all about creating history afresh, and they actively
discourage
empty commits to be (re)created.
There is no "uneven treatment".
36863af16e (git-commit --allow-empty) says "This is primarily for
use by foreign scm interface scripts.". Is this the only case
where empty commits _should_ be used?
If foreign scm recorded an empty commit, it would be nice to be
able to
recreate such a broken history _if the user wanted to_, and that is
where
the --allow-empty option can be used.
Thank you for the clarification. I will explain the source of my
confusion.
The current documentation "Usually recording [an empty commit] is a
mistake... This option ... is primarily for use by foreign scm
interface scripts." implied to me that there was room outside foreign
scm interface for "normal" use of empty commits.
My confusion was that I took "usually a mistake" to refer to the case
where the user meant to commit content changes but forgot to first
stage any changed content. But your clarification shows that "usually
a mistake" really means that making any empty commit, intentional or
not, is (considered to be) a fundamental misuse of SCM machinery.
Would it be acceptable to strengthen the language in the
documentation for --allow-empty? Possibly something like the
following paragraph:
Empty commits are a broken concept and should never be made during
normal usage. By default, the command prevents you
from making such a commit. This option bypasses the safety, and is
primarily for use by foreign scm interface scripts.
If such a change is acceptable, I will send a patch.
--
Chris
--
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
