From: Chris Johnsen Date: Sun, 08 Mar 2009 21:09:50 GMT Subject: Re: [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit Message-ID: In-Reply-To: <7v63ikmz11.fsf@gitster.siamese.dyndns.org> 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