{"thread":{"id":"23322","subject":"Does Git really need a commit message to go with a commit?","startedAt":"2010-04-03T22:06:16Z","lastAt":"2010-04-08T06:44:50Z","messageCount":35,"participants":["Ævar Arnfjörð Bjarmason","Avery Pennarun","Santi Béjar","David Aguilar","Junio C Hamano","Sverre Rabbelier","Miles Bader","Jeff King","Jonathan Nieder","Tay Ray Chuan","Johannes Sixt","Stephen Boyd"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"138516","messageId":"z2r51dd1af81004031506pc9ac1840ie9953ae6df91d01b@mail.gmail.com","threadId":"23322","inReplyTo":null,"subject":"Does Git really need a commit message to go with a commit?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-03T22:06:16Z","receivedAt":"2010-04-03T22:06:16Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"git-commit(1) doesn't allow you to make a commit without a commit\nmessage. This is annoying and doesn't properly preserve history in\napplications like snerp-vortex which replay a SVN dump into Git. You\nhave to add `$msg = \"Git made me do it\" unless length $msg' somewhere.\n\nIs there really no way to add a commit with no message with the git\ntools? Will anything break if I manually construct a commit with no\nmessage? Are commit messages inherently part of the format or does\ngit-commit(1) just think it knows better than me?\n"},{"id":"138521","messageId":"w2v32541b131004031858t692577a7p5009637f831bff46@mail.gmail.com","threadId":"23322","inReplyTo":"z2r51dd1af81004031506pc9ac1840ie9953ae6df91d01b@mail.gmail.com","subject":"Re: Does Git really need a commit message to go with a commit?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-04-04T01:58:23Z","receivedAt":"2010-04-04T01:58:23Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Sat, Apr 3, 2010 at 6:06 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> git-commit(1) doesn't allow you to make a commit without a commit\n> message. This is annoying and doesn't properly preserve history in\n> applications like snerp-vortex which replay a SVN dump into Git. You\n> have to add `$msg = \"Git made me do it\" unless length $msg' somewhere.\n>\n> Is there really no way to add a commit with no message with the git\n> tools? Will anything break if I manually construct a commit with no\n> message? Are commit messages inherently part of the format or does\n> git-commit(1) just think it knows better than me?\n\ngit-commit isn't really meant to be used by scripts.  Try using\ngit-commit-tree instead, which doesn't enforce a commit message.\n\n(Or use git fast-import; a quick glance at Snerp suggests that it's\nintended to be *fast*; using fast-import ought to make things vastly\nquicker.)\n\nAvery\n"},{"id":"138530","messageId":"n2madf1fd3d1004040537jd61d70c6we5ba3b294dfc10be@mail.gmail.com","threadId":"23322","inReplyTo":"h2m51dd1af81004040415xc7381f6cp1bf81bcfd684b99d@mail.gmail.com","subject":"Re: Does Git really need a commit message to go with a commit?","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2010-04-04T12:37:59Z","receivedAt":"2010-04-04T12:37:59Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Sun, Apr 4, 2010 at 1:15 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> On Sat, Apr 3, 2010 at 22:26, Santi Béjar <santi@agolina.net> wrote:\n>> On Sun, Apr 4, 2010 at 12:06 AM, Ævar Arnfjörð Bjarmason\n>> <avarab@gmail.com> wrote:\n>>> git-commit(1) doesn't allow you to make a commit without a commit\n>>> message. This is annoying and doesn't properly preserve history in\n>>> applications like snerp-vortex which replay a SVN dump into Git. You\n>>> have to add `$msg = \"Git made me do it\" unless length $msg' somewhere.\n>>>\n>>> Is there really no way to add a commit with no message with the git\n>>> tools? Will anything break if I manually construct a commit with no\n>>> message? Are commit messages inherently part of the format or does\n>>> git-commit(1) just think it knows better than me?\n>>\n>> Normally it does not make sense an empty commit message, so it is\n>> forbidden by default. But there is a flag (documented in the man page)\n>> since v1.5.4 (v1.5.3.7-994-g36863af git-commit --allow-empty,\n>> 2007-12-03) to allow it.\n>\n> Actually --allow-empty allows you to commit an empty /tree/. It\n> doesn't do anything for the commit message itself.\n\nArg! You are right, sorry for the noise. I should not write emails\nduring the night...\n\nI then suppose your only option is to use plumbing commands (see\ngit(1)), in this case git-commit-tree. In general if you write scripts\naround git you should use only plumbing commands as they don't change\nthe behavior.\n\nHTH,\nSanti\n"},{"id":"138539","messageId":"1270392557-26538-1-git-send-email-avarab@gmail.com","threadId":"23322","inReplyTo":"z2r51dd1af81004031506pc9ac1840ie9953ae6df91d01b@mail.gmail.com","subject":"[PATCH] Add option to git-commit to allow empty log messages","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-04T14:49:16Z","receivedAt":"2010-04-04T14:49:16Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Change git-commit(1) to accept a --allow-empty-message option\nanalogous to the existing --allow-empty option which allows empty\ntrees. This is mainly for compatability with foreign SCM systems.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n Documentation/git-commit.txt          |   12 +++++++--\n builtin/commit.c                      |    7 +++--\n t/t7510-commit-allow-empty-message.sh |   41 +++++++++++++++++++++++++++++++++\n 3 files changed, 54 insertions(+), 6 deletions(-)\n create mode 100755 t/t7510-commit-allow-empty-message.sh\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 64fb458..2c1c2e1 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -10,9 +10,9 @@ SYNOPSIS\n [verse]\n 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]\n \t   [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]\n-\t   [--allow-empty] [--no-verify] [-e] [--author=<author>]\n-\t   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]\n-\t   [[-i | -o ]<file>...]\n+\t   [--allow-empty] [--allow-empty-message] [--no-verify] [-e]\n+\t   [--author=<author>] [--date=<date>] [--cleanup=<mode>]\n+\t   [--status | --no-status] [--] [[-i | -o ]<file>...]\n \n DESCRIPTION\n -----------\n@@ -131,6 +131,12 @@ OPTIONS\n \tfrom making such a commit.  This option bypasses the safety, and\n \tis primarily for use by foreign scm interface scripts.\n \n+--allow-empty-message::\n+\tLike --allow-empty this command is primarily for use by foreign\n+\tscm interface scripts. It allows you to create a commit with an\n+\tempty commit message without using plumbing commands like\n+\tlinkgit:git-commit-tree[1].\n+\n --cleanup=<mode>::\n \tThis option sets how the commit message is cleaned up.\n \tThe  '<mode>' can be one of 'verbatim', 'whitespace', 'strip',\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex c5ab683..7fd963e 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -65,8 +65,8 @@ static const char *template_file;\n static char *edit_message, *use_message;\n static char *author_name, *author_email, *author_date;\n static int all, edit_flag, also, interactive, only, amend, signoff;\n-static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;\n-static int no_post_rewrite;\n+static int quiet, verbose, no_verify, allow_empty, allow_empty_message, dry_run;\n+static int no_post_rewrite, renew_authorship;\n static char *untracked_files_arg, *force_date;\n /*\n  * The default commit message cleanup mode will remove the lines\n@@ -141,6 +141,7 @@ static struct option builtin_commit_options[] = {\n \tOPT_BOOLEAN(0, \"no-post-rewrite\", &no_post_rewrite, \"bypass post-rewrite hook\"),\n \t{ OPTION_STRING, 'u', \"untracked-files\", &untracked_files_arg, \"mode\", \"show untracked files, optional modes: all, normal, no. (Default: all)\", PARSE_OPT_OPTARG, NULL, (intptr_t)\"all\" },\n \tOPT_BOOLEAN(0, \"allow-empty\", &allow_empty, \"ok to record an empty change\"),\n+\tOPT_BOOLEAN(0, \"allow-empty-message\", &allow_empty_message, \"ok to record a change with an empty message\"),\n \t/* end commit contents options */\n \n \tOPT_END()\n@@ -1293,7 +1294,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \n \tif (cleanup_mode != CLEANUP_NONE)\n \t\tstripspace(&sb, cleanup_mode == CLEANUP_ALL);\n-\tif (message_is_empty(&sb)) {\n+\tif (message_is_empty(&sb) && !allow_empty_message) {\n \t\trollback_index_files();\n \t\tfprintf(stderr, \"Aborting commit due to empty commit message.\\n\");\n \t\texit(1);\ndiff --git a/t/t7510-commit-allow-empty-message.sh b/t/t7510-commit-allow-empty-message.sh\nnew file mode 100755\nindex 0000000..d7dc0da\n--- /dev/null\n+++ b/t/t7510-commit-allow-empty-message.sh\n@@ -0,0 +1,41 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2010 Ævar Arnfjörð Bjarmason\n+#\n+\n+test_description='git commit --allow-empty-message'\n+\n+. ./test-lib.sh\n+\n+commit_msg_is () {\n+\ttest \"`git log --pretty=format:%s%b -1`\" = \"$1\"\n+}\n+\n+# A sanity check to see if commit is working at all.\n+test_expect_success 'a basic commit in an empty tree should succeed' '\n+\t(\n+\t\techo content > foo &&\n+\t\tgit add foo &&\n+\t\tgit commit -m \"initial commit\"\n+\t) &&\n+\tcommit_msg_is \"initial commit\"\n+'\n+\n+test_expect_success 'Commit no message with --allow-empty-message' '\n+\t(\n+\t\techo \"more content\" >> foo &&\n+\t\tgit add foo &&\n+\t\tprintf \"\" | git commit --allow-empty-message\n+\t) &&\n+\tcommit_msg_is \"\"\n+'\n+\n+test_expect_success 'Commit a message with --allow-empty-message' '\n+\t(\n+\t\techo \"even more content\" >> foo &&\n+\t\tgit add foo &&\n+\t\tgit commit --allow-empty-message -m\"hello there\"\n+\t) &&\n+\tcommit_msg_is \"hello there\"\n+'\n+test_done\n-- \n1.7.0.4.298.gc81d\n"},{"id":"138571","messageId":"20100404224324.GB12655@gmail.com","threadId":"23322","inReplyTo":"1270392557-26538-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2010-04-04T22:43:25Z","receivedAt":"2010-04-04T22:43:25Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sun, Apr 04, 2010 at 02:49:16PM +0000, Ævar Arnfjörð Bjarmason wrote:\n> Change git-commit(1) to accept a --allow-empty-message option\n> analogous to the existing --allow-empty option which allows empty\n> trees. This is mainly for compatability with foreign SCM systems.\n\nIt's hard enough to get co-workers to write good commit\nmessages.  I wouldn't want to encourage them to skip writing\nthem altogether (by the existence of this feature).\n\nIs there any reason why the git commit-tree plumbing didn't\nsuffice?\n\n(in other words, \"sure we can\", but I'm asking,\n \"are you sure we should?\")\n\nJust my $.02.\nHey, we just had a small earthquake.  Fun =)\n\n\n> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n> ---\n>  Documentation/git-commit.txt          |   12 +++++++--\n>  builtin/commit.c                      |    7 +++--\n>  t/t7510-commit-allow-empty-message.sh |   41 +++++++++++++++++++++++++++++++++\n>  3 files changed, 54 insertions(+), 6 deletions(-)\n>  create mode 100755 t/t7510-commit-allow-empty-message.sh\n> \n> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\n> index 64fb458..2c1c2e1 100644\n> --- a/Documentation/git-commit.txt\n> +++ b/Documentation/git-commit.txt\n> @@ -10,9 +10,9 @@ SYNOPSIS\n>  [verse]\n>  'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]\n>  \t   [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]\n> -\t   [--allow-empty] [--no-verify] [-e] [--author=<author>]\n> -\t   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]\n> -\t   [[-i | -o ]<file>...]\n> +\t   [--allow-empty] [--allow-empty-message] [--no-verify] [-e]\n> +\t   [--author=<author>] [--date=<date>] [--cleanup=<mode>]\n> +\t   [--status | --no-status] [--] [[-i | -o ]<file>...]\n>  \n>  DESCRIPTION\n>  -----------\n> @@ -131,6 +131,12 @@ OPTIONS\n>  \tfrom making such a commit.  This option bypasses the safety, and\n>  \tis primarily for use by foreign scm interface scripts.\n>  \n> +--allow-empty-message::\n> +\tLike --allow-empty this command is primarily for use by foreign\n> +\tscm interface scripts. It allows you to create a commit with an\n> +\tempty commit message without using plumbing commands like\n> +\tlinkgit:git-commit-tree[1].\n> +\n>  --cleanup=<mode>::\n>  \tThis option sets how the commit message is cleaned up.\n>  \tThe  '<mode>' can be one of 'verbatim', 'whitespace', 'strip',\n> diff --git a/builtin/commit.c b/builtin/commit.c\n> index c5ab683..7fd963e 100644\n> --- a/builtin/commit.c\n> +++ b/builtin/commit.c\n> @@ -65,8 +65,8 @@ static const char *template_file;\n>  static char *edit_message, *use_message;\n>  static char *author_name, *author_email, *author_date;\n>  static int all, edit_flag, also, interactive, only, amend, signoff;\n> -static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;\n> -static int no_post_rewrite;\n> +static int quiet, verbose, no_verify, allow_empty, allow_empty_message, dry_run;\n> +static int no_post_rewrite, renew_authorship;\n>  static char *untracked_files_arg, *force_date;\n>  /*\n>   * The default commit message cleanup mode will remove the lines\n> @@ -141,6 +141,7 @@ static struct option builtin_commit_options[] = {\n>  \tOPT_BOOLEAN(0, \"no-post-rewrite\", &no_post_rewrite, \"bypass post-rewrite hook\"),\n>  \t{ OPTION_STRING, 'u', \"untracked-files\", &untracked_files_arg, \"mode\", \"show untracked files, optional modes: all, normal, no. (Default: all)\", PARSE_OPT_OPTARG, NULL, (intptr_t)\"all\" },\n>  \tOPT_BOOLEAN(0, \"allow-empty\", &allow_empty, \"ok to record an empty change\"),\n> +\tOPT_BOOLEAN(0, \"allow-empty-message\", &allow_empty_message, \"ok to record a change with an empty message\"),\n>  \t/* end commit contents options */\n>  \n>  \tOPT_END()\n> @@ -1293,7 +1294,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n>  \n>  \tif (cleanup_mode != CLEANUP_NONE)\n>  \t\tstripspace(&sb, cleanup_mode == CLEANUP_ALL);\n> -\tif (message_is_empty(&sb)) {\n> +\tif (message_is_empty(&sb) && !allow_empty_message) {\n>  \t\trollback_index_files();\n>  \t\tfprintf(stderr, \"Aborting commit due to empty commit message.\\n\");\n>  \t\texit(1);\n> diff --git a/t/t7510-commit-allow-empty-message.sh b/t/t7510-commit-allow-empty-message.sh\n> new file mode 100755\n> index 0000000..d7dc0da\n> --- /dev/null\n> +++ b/t/t7510-commit-allow-empty-message.sh\n> @@ -0,0 +1,41 @@\n> +#!/bin/sh\n> +#\n> +# Copyright (c) 2010 Ævar Arnfjörð Bjarmason\n> +#\n> +\n> +test_description='git commit --allow-empty-message'\n> +\n> +. ./test-lib.sh\n> +\n> +commit_msg_is () {\n> +\ttest \"`git log --pretty=format:%s%b -1`\" = \"$1\"\n> +}\n> +\n> +# A sanity check to see if commit is working at all.\n> +test_expect_success 'a basic commit in an empty tree should succeed' '\n> +\t(\n> +\t\techo content > foo &&\n> +\t\tgit add foo &&\n> +\t\tgit commit -m \"initial commit\"\n> +\t) &&\n> +\tcommit_msg_is \"initial commit\"\n> +'\n> +\n> +test_expect_success 'Commit no message with --allow-empty-message' '\n> +\t(\n> +\t\techo \"more content\" >> foo &&\n> +\t\tgit add foo &&\n> +\t\tprintf \"\" | git commit --allow-empty-message\n> +\t) &&\n> +\tcommit_msg_is \"\"\n> +'\n> +\n> +test_expect_success 'Commit a message with --allow-empty-message' '\n> +\t(\n> +\t\techo \"even more content\" >> foo &&\n> +\t\tgit add foo &&\n> +\t\tgit commit --allow-empty-message -m\"hello there\"\n> +\t) &&\n> +\tcommit_msg_is \"hello there\"\n> +'\n> +test_done\n> -- \n> 1.7.0.4.298.gc81d\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\n-- \n\t\tDavid\n"},{"id":"138572","messageId":"y2j51dd1af81004041653g9a09915el60104c575dcf6481@mail.gmail.com","threadId":"23322","inReplyTo":"20100404224324.GB12655@gmail.com","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-04T23:53:26Z","receivedAt":"2010-04-04T23:53:26Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"In retrospect I probably should have sent a [PATCH RFC], this is\nobviously somewhat of a delicate subject.\n\nOn Sun, Apr 4, 2010 at 21:21, Shawn Pearce <spearce@spearce.org> wrote:\n> Isn't this exactly why git-commit-tree exists?  I don't really see a reason\n> to support scripting the porcelain git commit.\n\nIt's not so much about supporting scripting as exporting the\ncapabilities of the porcelain to the frontend utilities without\nartificial limitations.\n\nOn Sun, Apr 4, 2010 at 22:43, David Aguilar <davvid@gmail.com> wrote:\n> On Sun, Apr 04, 2010 at 02:49:16PM +0000, Ævar Arnfjörð Bjarmason wrote:\n>> Change git-commit(1) to accept a --allow-empty-message option\n>> analogous to the existing --allow-empty option which allows empty\n>> trees. This is mainly for compatability with foreign SCM systems.\n>\n> Is there any reason why the git commit-tree plumbing didn't\n> suffice?\n\nI encountered this limitation most recently while using hacking\nsnerp-vortex which uses git-commit(1) directly. While it should\nideally use git-commit-tree(1) or git-fast-import(1) it was easier at\nthe time to do:\n\n    message ||= \"Git made me\";\n\nI thought it was silly that I had to either do that to fix an\notherwise working piece of software or rewrite how it does commits,\nhence the patch.\n\n> It's hard enough to get co-workers to write good commit\n> messages.  I wouldn't want to encourage them to skip writing\n> them altogether (by the existence of this feature).\n\nI'm a big fan of good commit messages, that's another reason why I\nthink this feature is a good idea.\n\nI've read too many commit messages from people who're obviously\ndetermined not to write any, but are being forced to do so by their\ntools. Favorites include \"more updates\", \"some changes\", \"...\" (the\nlist goes on). I'd rather get nothing at all from those people than\nmore meaningless drivel. It would increase the signal-to-noise ratio\nof git-log(1) output.\n"},{"id":"138575","messageId":"7vy6h2wsvg.fsf@alter.siamese.dyndns.org","threadId":"23322","inReplyTo":"y2j51dd1af81004041653g9a09915el60104c575dcf6481@mail.gmail.com","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-05T02:11:31Z","receivedAt":"2010-04-05T02:11:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> It's not so much about supporting scripting as exporting the\n> capabilities of the porcelain to the frontend utilities without\n> artificial limitations.\n\nAs a Porcelain, \"git commit\" has some leeway to enforce sensible policy on\nthe users, and \"forbid commit that does not explain anything\" is one such\npolicy.  It is not generally a good idea to expose the full capabilities\nof plumbing to Porcelain if it leads to bad user behaviour, and such\n\"artificial\" limitations are safety features we do not want to remove.\n"},{"id":"138576","messageId":"h2rfabb9a1e1004041915u3754016cr10e874c12f2a24e6@mail.gmail.com","threadId":"23322","inReplyTo":"7vy6h2wsvg.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-05T02:15:13Z","receivedAt":"2010-04-05T02:15:13Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Apr 4, 2010 at 21:11, Junio C Hamano <gitster@pobox.com> wrote:\n> As a Porcelain, \"git commit\" has some leeway to enforce sensible policy on\n> the users, and \"forbid commit that does not explain anything\" is one such\n> policy.  It is not generally a good idea to expose the full capabilities\n> of plumbing to Porcelain if it leads to bad user behaviour, and such\n> \"artificial\" limitations are safety features we do not want to remove.\n\nYou contradict yourself:\n\ncommit 5241b6bfe2285a6da598a0348c37b77964035bc8\nAuthor: Junio C Hamano <gitster@pobox.com>\nDate:   Mon Dec 3 00:03:10 2007 -0800\n\n    git-commit --allow-empty\n\n    It does not usually make sense to record a commit that has the exact\n    same tree as its sole parent commit and that is why git-commit prevents\n    you from making such a mistake, but when data from foreign scm is\n    involved, it is a different story.  We are equipped to represent such an\n    (perhaps insane, perhaps by mistake, or perhaps done on purpose) empty\n    change, and it is better to represent it bypassing the safety valve for\n    native use.\n\n    This is primarily for use by foreign scm interface scripts.\n\n    Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"138577","messageId":"7vy6h2pn51.fsf@alter.siamese.dyndns.org","threadId":"23322","inReplyTo":"h2rfabb9a1e1004041915u3754016cr10e874c12f2a24e6@mail.gmail.com","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-05T03:57:14Z","receivedAt":"2010-04-05T03:57:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> On Sun, Apr 4, 2010 at 21:11, Junio C Hamano <gitster@pobox.com> wrote:\n>> As a Porcelain, \"git commit\" has some leeway to enforce sensible policy on\n>> the users, and \"forbid commit that does not explain anything\" is one such\n>> policy.  It is not generally a good idea to expose the full capabilities\n>> of plumbing to Porcelain if it leads to bad user behaviour, and such\n>> \"artificial\" limitations are safety features we do not want to remove.\n>\n> You contradict yourself:\n\nI personally don't mind very much removing --allow-empty, though.\n"},{"id":"138578","messageId":"buor5mu7acd.fsf@dhlpc061.dev.necel.com","threadId":"23322","inReplyTo":"7vy6h2wsvg.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-04-05T05:10:58Z","receivedAt":"2010-04-05T05:10:58Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n> As a Porcelain, \"git commit\" has some leeway to enforce sensible policy on\n> the users, and \"forbid commit that does not explain anything\" is one such\n> policy.  It is not generally a good idea to expose the full capabilities\n> of plumbing to Porcelain if it leads to bad user behaviour, and such\n> \"artificial\" limitations are safety features we do not want to remove.\n\nIsn't the requirement of using a longish option like\n\"--allow-empty-message\" enough of a warning to users though?\n\nAlthough it seems reasonable for git _discourage_ bad practices, I think\nthat should generally also be moderated with \"... but if you _reallllly_\nwant to, you can do this somewhat annoying thing....\".  Forcing someone\nto use commit-tree, though, seems a bit much to me; an annoyingly long\noption seems about right.\n\n-Miles\n\n-- \nLove is the difficult realization that something other than oneself is real.\n[Iris Murdoch]\n"},{"id":"138579","messageId":"7vsk7apiyt.fsf@alter.siamese.dyndns.org","threadId":"23322","inReplyTo":"buor5mu7acd.fsf@dhlpc061.dev.necel.com","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-05T05:27:22Z","receivedAt":"2010-04-05T05:27:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader <miles@gnu.org> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>> As a Porcelain, \"git commit\" has some leeway to enforce sensible policy on\n>> the users, and \"forbid commit that does not explain anything\" is one such\n>> policy.  It is not generally a good idea to expose the full capabilities\n>> of plumbing to Porcelain if it leads to bad user behaviour, and such\n>> \"artificial\" limitations are safety features we do not want to remove.\n>\n> Isn't the requirement of using a longish option like\n> \"--allow-empty-message\" enough of a warning to users though?\n\nYes, but re-read the part you omitted from your quote, where Ævar makes it\nsound as if exposing plumbing's flexibility to the Porcelain layer is\nunconditionally a good thing.  My point is it never is.\n\nAnd as you said (and as Sverre alluded to with his --allow-empty), longish\noption is one way to ensure that we do not unconditionally expose\nflexibility from the plumbing without thinking.\n"},{"id":"138580","messageId":"20100405055139.GA28730@coredump.intra.peff.net","threadId":"23322","inReplyTo":"buor5mu7acd.fsf@dhlpc061.dev.necel.com","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-05T05:51:39Z","receivedAt":"2010-04-05T05:51:39Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 05, 2010 at 02:10:58PM +0900, Miles Bader wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> > As a Porcelain, \"git commit\" has some leeway to enforce sensible policy on\n> > the users, and \"forbid commit that does not explain anything\" is one such\n> > policy.  It is not generally a good idea to expose the full capabilities\n> > of plumbing to Porcelain if it leads to bad user behaviour, and such\n> > \"artificial\" limitations are safety features we do not want to remove.\n> \n> Isn't the requirement of using a longish option like\n> \"--allow-empty-message\" enough of a warning to users though?\n> \n> Although it seems reasonable for git _discourage_ bad practices, I think\n> that should generally also be moderated with \"... but if you _reallllly_\n> want to, you can do this somewhat annoying thing....\".  Forcing someone\n> to use commit-tree, though, seems a bit much to me; an annoyingly long\n> option seems about right.\n\nYes and no. There are other reasons not to use \"git commit\" in your\nimport script. You probably want to pass --allow-empty, too, and\n--no-verify.  And you probably want to use --cleanup=none to keep\nmessages intact.\n\nBut most of all, even if you do everything right, we still don't promise\nnot to change it out from under you in a future version. Because it's\nporcelain, and the plumbing method is to use commit-tree.  If\ncommit-tree is too hard to use, I would rather see the plumbing made\nmore friendly than encouraging people to build on top of porcelain.\n\nAll of that being said, I looked at the snerp-vortex source code (which\nstarted this thread):\n\n  http://github.com/rcaputo/snerp-vortex/blob/master/lib/SVN/Dump/Replayer/Git.pm\n\nIt uses several pieces of porcelain. Some in silly ways, like calling\n\"git status\" to avoid calling git-commit when there are no changes and\ngetting an error code. Which is silly (if you are importing, you\nprobably want --allow-empty), wasteful (you just need the diff-index\npart of status), and now broken (because status is no longer \"commit\n--dry-run\", it always exits with status 0 whether there are changes or\nnot). Then there are things like calling \"git add -f\" with arguments,\nand a \"TODO: split arguments to handle larger filesets\" comment. When he\nshould be using update-index, which takes updates on stdin.\n\nHe also notes in the README that it takes 250 seconds to convert his\ntest repo to git, but only 70 to make a flat filesystem, and that he\nwants to move to using fast-import.\n\nSo yes, it sucks that his importer does not support empty comments, and\nthat the OP had to hack around it. But it already doesn't support many\nthings (like commits with a large number of files, and from what I can\nsee, files with spaces will break his `find` invocation). The right\nanswer is for him to move to fast-import, which will be way faster, more\nrobust, and is actually a supported plumbing interface.\n\nI don't think it's worth adding new features to support a scripting\ninterface that we are trying to discourage. And I haven't seen another\nargument in favor of empty commits besides importing.  Are people\nreally wanting to make empty commit messages while using git itself?\n\n-Peff\n"},{"id":"138589","messageId":"o2h51dd1af81004050550v9427b9flfb13a9e1ad4056a@mail.gmail.com","threadId":"23322","inReplyTo":"20100405055139.GA28730@coredump.intra.peff.net","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-05T12:50:11Z","receivedAt":"2010-04-05T12:50:11Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Apr 5, 2010 at 05:51, Jeff King <peff@peff.net> wrote:\n> So yes, it sucks that his importer does not support empty comments, and\n> that the OP had to hack around it. But it already doesn't support many\n> things (like commits with a large number of files, and from what I can\n> see, files with spaces will break his `find` invocation). The right\n> answer is for him to move to fast-import, which will be way faster, more\n> robust, and is actually a supported plumbing interface.\n\nThanks for looking at the importer, that'll be very useful when fixing\nit. But FWIW that `find` invocation isn't a bug. Perl doesn't have a \"\n\" input field separator so \"my @files = `find . -type f`\" does the\nright thing, unlike in the shell.\n\n> I don't think it's worth adding new features to support a scripting\n> interface that we are trying to discourage. And I haven't seen another\n> argument in favor of empty commits besides importing.  Are people\n> really wanting to make empty commit messages while using git itself?\n\nI'm sorry that I brought snerp-vortex into this at all. It wasn't the\nmain motivation behind this patch, just the straw that broke the\ncamel's back.\n\nI've run into this limitation a lot when playing with and learning\nGit. Sometimes I'm e.g. making small throwaway repositories in /tmp\nusing the porcelain for  experimentation. Those have seen a lot of\n\"blah!\" commit messages immediately following \"Git exited abnormally\nwith code 1\".\n\nMiles Bader said it better than I could. Tools should provide sane\ndefaults and discourage bad practices, but they shouldn't *enforce*\ngood practices. That'll inevitably burn people whose use for the tools\nisn't what you expect.\n\nEven if they Git maintainers don't like this people *do* write\nautomated scripts and wrappers around Git using the porcelain, simply\nbecause that's what they're used to. Learning to use and switching to\nsomething like git-fast-import(1) or git-commit-tree(1) is too big of\na hurdle for small throwaway scripts that take ~1m to write and aren't\nbig dedicated importers like snerp-vortex.\n\nThere's probably a lot of code out there doing `git commit -m\"Yet\nanother revision\"' from some cron job. I sprinkled a lot of such\nmeaningless messages about when I switched from Subversion (which\nsupports empty commits in the porcelain) for these automated jobs to\nGit.\n\nOf course Junio may disagree (and that's fine!), how much you babysit\nyour users is ultimately a design decision up to the maintainer. I\njust find this inconsistent with the rest of the porcelain which\nusually gives me plenty of ammo to blow both my legs of (and the\nplanet they were standing on) if I so choose :)\n"},{"id":"138597","messageId":"k2lfabb9a1e1004050746if7efaa74k62be6c1f3f97053@mail.gmail.com","threadId":"23322","inReplyTo":"7vy6h2pn51.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-05T14:46:47Z","receivedAt":"2010-04-05T14:46:47Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Apr 4, 2010 at 22:57, Junio C Hamano <gitster@pobox.com> wrote:\n> Sverre Rabbelier <srabbelier@gmail.com> writes:\n>> You contradict yourself:\n>\n> I personally don't mind very much removing --allow-empty, though.\n\nAh, hmm. I vaguely remember some discussion in the past about empty\ncommits, but I'm not sure what the conclusion there was? I think it\nwas something like \"if you want to create a marker, use tags instead,\nthere's really no reason to be using --allow-empty\". Wasn't there some\nuse case for \"--allow-emtpy\" when creating an unrooted branch with an\nempty starting point, or somesuch?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"138605","messageId":"20100405175822.GA32083@progeny.tock","threadId":"23322","inReplyTo":"o2h51dd1af81004050550v9427b9flfb13a9e1ad4056a@mail.gmail.com","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-05T17:58:22Z","receivedAt":"2010-04-05T17:58:22Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nÆvar Arnfjörð Bjarmason wrote:\n\n> Learning to use and switching to\n> something like git-fast-import(1) or git-commit-tree(1) is too big of\n> a hurdle for small throwaway scripts that take ~1m to write and aren't\n> big dedicated importers like snerp-vortex.\n> \n> There's probably a lot of code out there doing `git commit -m\"Yet\n> another revision\"' from some cron job.\n\nFWIW, I have no strong opinion about whether to add this --allow-empty-message\noption.  Maybe it would make something more convenient for someone,\nthough that has to be weighed against it making it harder for everyone\nelse to read the manual.\n\nInstead, I just wanted to suggest that it is really worth the time to\nlearn to use ‘git commit-tree’.  Mostly because it does not take much\ntime to learn at all.\n\nHint:\n\n\tparent=HEAD && : or whatever &&\n\ttree=$(git write-tree) &&\n\tprintf \"%s\\n\" message |\n\tcommit=$(git commit-tree \"$tree\" -p \"$parent\") &&\n\tgit update-ref refs/heads/somebranch \"$commit\"\n\nIt is a very flexible tool, and I think you will find yourself fighting\nwith git much less if you use tools like it in situations that would\nbe unusual for a human to run into.\n\nCheers,\nJonathan\n"},{"id":"138606","messageId":"20100405181152.GA32188@progeny.tock","threadId":"23322","inReplyTo":"20100405175822.GA32083@progeny.tock","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-05T18:11:52Z","receivedAt":"2010-04-05T18:11:52Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> \tparent=HEAD && : or whatever &&\n> \ttree=$(git write-tree) &&\n> \tprintf \"%s\\n\" message |\n> \tcommit=$(git commit-tree \"$tree\" -p \"$parent\") &&\n> \tgit update-ref refs/heads/somebranch \"$commit\"\n\nI rearranged this example the last minute and broke it.  You might\nsay this proves the opposite of my point, though I don’t think that\nwould be warranted.  Anyway, to feed the message into ‘git\ncommit-tree’ standard input, the relevant part of the example should\nhave read as follows:\n\ncommit=$(\n\tprintf \"%s\\n\" message |\n\tgit commit-tree \"$tree\" -p \"$parent\"\n)\n\nIncidentally, outside of the user manual and contrib/examples/ in the\nsources, the git documentation does not have many examples like this\nto point to, which is too bad.\n\nSorry for the confusion,\nJonathan\n"},{"id":"138708","messageId":"20100406054356.GD3901@coredump.intra.peff.net","threadId":"23322","inReplyTo":"o2h51dd1af81004050550v9427b9flfb13a9e1ad4056a@mail.gmail.com","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-06T05:43:56Z","receivedAt":"2010-04-06T05:43:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 05, 2010 at 12:50:11PM +0000, Ævar Arnfjörð Bjarmason wrote:\n\n> Thanks for looking at the importer, that'll be very useful when fixing\n> it. But FWIW that `find` invocation isn't a bug. Perl doesn't have a \"\n> \" input field separator so \"my @files = `find . -type f`\" does the\n> right thing, unlike in the shell.\n\nHe calls `find $dir -type f`, without a quotemeta on $dir, which perl\nwill pass to the shell to interpret (and is actually a security issue if\nI can convince you to try importing my svn repository with directory ';\nrm -rf /;').\n\n> I'm sorry that I brought snerp-vortex into this at all. It wasn't the\n> main motivation behind this patch, just the straw that broke the\n> camel's back.\n\nI don't in particular have a problem with --allow-empty-message for\ncasual use. Why anybody would want to use it when they could type the\nmuch shorter -mnone, I don't know. But it is long enough that people\nwill have to think about using it, which means the people who do so will\nprobably really want it.\n\n-Peff\n"},{"id":"138709","messageId":"20100406055530.GE3901@coredump.intra.peff.net","threadId":"23322","inReplyTo":"20100405175822.GA32083@progeny.tock","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-06T05:55:30Z","receivedAt":"2010-04-06T05:55:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 05, 2010 at 12:58:22PM -0500, Jonathan Nieder wrote:\n\n> > There's probably a lot of code out there doing `git commit -m\"Yet\n> > another revision\"' from some cron job.\n> \n> FWIW, I have no strong opinion about whether to add this --allow-empty-message\n> option.  Maybe it would make something more convenient for someone,\n> though that has to be weighed against it making it harder for everyone\n> else to read the manual.\n\nI meant to mention this in my other response: I would prefer if such an\noption doesn't clutter up the usage message. --allow-empty is already\nthere, and probably doesn't need to be. \"git commit -h 2>&1 | wc -l\"\nshows a whopping 39 lines, which IMHO is too many for a short usage\nsummary. I mean, \"--no-post-rewrite\", is that really one of the top-used\noptions?\n\n> Hint:\n> \n> \tparent=HEAD && : or whatever &&\n> \ttree=$(git write-tree) &&\n> \tprintf \"%s\\n\" message |\n> \tcommit=$(git commit-tree \"$tree\" -p \"$parent\") &&\n> \tgit update-ref refs/heads/somebranch \"$commit\"\n\nIn addition to the bug you mention later, you also probably want to do:\n\n  parent=`git rev-parse --verify HEAD`\n  [...]\n  git update-ref \\\n    -m 'automated commit by tool X' \\\n    refs/heads/somebranch $commit $parent\n\nwhich will give your reflog entry a more useful message, and will\nprotect against simultaneous updates losing history (update-ref will\nmake sure, while locked, that somebranch contains the $parent sha1 you\nwrote as part of the commit object).\n\nAnd of course it still doesn't handle parentless root commits.\n\nSo doing it right really is a bit more work than just calling \"git\ncommit\".\n\n-Peff\n"},{"id":"138724","messageId":"1270543235-8570-1-git-send-email-avarab@gmail.com","threadId":"23322","inReplyTo":"20100406055530.GE3901@coredump.intra.peff.net","subject":"[PATCH v2] Add option to git-commit to allow empty log messages","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-06T08:40:35Z","receivedAt":"2010-04-06T08:40:35Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Change git-commit(1) to accept a --allow-empty-message option\nanalogous to the existing --allow-empty option which allows empty\ntrees. This is mainly for compatability with foreign SCM systems.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n Documentation/git-commit.txt          |    6 +++++\n builtin/commit.c                      |    7 +++--\n t/t7510-commit-allow-empty-message.sh |   41 +++++++++++++++++++++++++++++++++\n 3 files changed, 51 insertions(+), 3 deletions(-)\n create mode 100755 t/t7510-commit-allow-empty-message.sh\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 64fb458..aa18bee 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -131,6 +131,12 @@ OPTIONS\n \tfrom making such a commit.  This option bypasses the safety, and\n \tis primarily for use by foreign scm interface scripts.\n \n+--allow-empty-message::\n+       Like --allow-empty this command is primarily for use by foreign\n+       scm interface scripts. It allows you to create a commit with an\n+       empty commit message without using plumbing commands like\n+       linkgit:git-commit-tree[1].\n+\n --cleanup=<mode>::\n \tThis option sets how the commit message is cleaned up.\n \tThe  '<mode>' can be one of 'verbatim', 'whitespace', 'strip',\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex c5ab683..7fd963e 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -65,8 +65,8 @@ static const char *template_file;\n static char *edit_message, *use_message;\n static char *author_name, *author_email, *author_date;\n static int all, edit_flag, also, interactive, only, amend, signoff;\n-static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;\n-static int no_post_rewrite;\n+static int quiet, verbose, no_verify, allow_empty, allow_empty_message, dry_run;\n+static int no_post_rewrite, renew_authorship;\n static char *untracked_files_arg, *force_date;\n /*\n  * The default commit message cleanup mode will remove the lines\n@@ -141,6 +141,7 @@ static struct option builtin_commit_options[] = {\n \tOPT_BOOLEAN(0, \"no-post-rewrite\", &no_post_rewrite, \"bypass post-rewrite hook\"),\n \t{ OPTION_STRING, 'u', \"untracked-files\", &untracked_files_arg, \"mode\", \"show untracked files, optional modes: all, normal, no. (Default: all)\", PARSE_OPT_OPTARG, NULL, (intptr_t)\"all\" },\n \tOPT_BOOLEAN(0, \"allow-empty\", &allow_empty, \"ok to record an empty change\"),\n+\tOPT_BOOLEAN(0, \"allow-empty-message\", &allow_empty_message, \"ok to record a change with an empty message\"),\n \t/* end commit contents options */\n \n \tOPT_END()\n@@ -1293,7 +1294,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \n \tif (cleanup_mode != CLEANUP_NONE)\n \t\tstripspace(&sb, cleanup_mode == CLEANUP_ALL);\n-\tif (message_is_empty(&sb)) {\n+\tif (message_is_empty(&sb) && !allow_empty_message) {\n \t\trollback_index_files();\n \t\tfprintf(stderr, \"Aborting commit due to empty commit message.\\n\");\n \t\texit(1);\ndiff --git a/t/t7510-commit-allow-empty-message.sh b/t/t7510-commit-allow-empty-message.sh\nnew file mode 100755\nindex 0000000..d7dc0da\n--- /dev/null\n+++ b/t/t7510-commit-allow-empty-message.sh\n@@ -0,0 +1,41 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2010 Ævar Arnfjörð Bjarmason\n+#\n+\n+test_description='git commit --allow-empty-message'\n+\n+. ./test-lib.sh\n+\n+commit_msg_is () {\n+\ttest \"`git log --pretty=format:%s%b -1`\" = \"$1\"\n+}\n+\n+# A sanity check to see if commit is working at all.\n+test_expect_success 'a basic commit in an empty tree should succeed' '\n+\t(\n+\t\techo content > foo &&\n+\t\tgit add foo &&\n+\t\tgit commit -m \"initial commit\"\n+\t) &&\n+\tcommit_msg_is \"initial commit\"\n+'\n+\n+test_expect_success 'Commit no message with --allow-empty-message' '\n+\t(\n+\t\techo \"more content\" >> foo &&\n+\t\tgit add foo &&\n+\t\tprintf \"\" | git commit --allow-empty-message\n+\t) &&\n+\tcommit_msg_is \"\"\n+'\n+\n+test_expect_success 'Commit a message with --allow-empty-message' '\n+\t(\n+\t\techo \"even more content\" >> foo &&\n+\t\tgit add foo &&\n+\t\tgit commit --allow-empty-message -m\"hello there\"\n+\t) &&\n+\tcommit_msg_is \"hello there\"\n+'\n+test_done\n-- \n1.7.0.4.298.gc81d\n"},{"id":"138725","messageId":"h2h51dd1af81004060142p25194aaai58492f617419d0f8@mail.gmail.com","threadId":"23322","inReplyTo":"20100406055530.GE3901@coredump.intra.peff.net","subject":"Re: [PATCH] Add option to git-commit to allow empty log messages","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-06T08:42:10Z","receivedAt":"2010-04-06T08:42:10Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Apr 6, 2010 at 05:55, Jeff King <peff@peff.net> wrote:\n> On Mon, Apr 05, 2010 at 12:58:22PM -0500, Jonathan Nieder wrote:\n>\n>> > There's probably a lot of code out there doing `git commit -m\"Yet\n>> > another revision\"' from some cron job.\n>>\n>> FWIW, I have no strong opinion about whether to add this --allow-empty-message\n>> option.  Maybe it would make something more convenient for someone,\n>> though that has to be weighed against it making it harder for everyone\n>> else to read the manual.\n>\n> I meant to mention this in my other response: I would prefer if such an\n> option doesn't clutter up the usage message. --allow-empty is already\n> there, and probably doesn't need to be. \"git commit -h 2>&1 | wc -l\"\n> shows a whopping 39 lines, which IMHO is too many for a short usage\n> summary. I mean, \"--no-post-rewrite\", is that really one of the top-used\n> options?\n\nI just put it there because --allow-empty was there and I thought the\nSYNOPSIS might be going for a complete listing. I completely agree\nthough, the option shouldn't be in the SYNOPSIS, and neither should\n--allow-empty be. They're both analogous to obscure options like\n--porcelain (which isn't listed).\n\nI've just submitted a new patch to rectify this. I can send another\none to remove --allow-empty from the SYNOPSIS.\n"},{"id":"138801","messageId":"7vsk77g7um.fsf@alter.siamese.dyndns.org","threadId":"23322","inReplyTo":"1270543235-8570-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH v2] Add option to git-commit to allow empty log messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-07T05:16:49Z","receivedAt":"2010-04-07T05:16:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> diff --git a/t/t7510-commit-allow-empty-message.sh b/t/t7510-commit-allow-empty-message.sh\n> new file mode 100755\n> index 0000000..d7dc0da\n\nI do not think a separate script is worth it.  I'd just add tests to t7500.\n\n> +test_expect_success 'a basic commit in an empty tree should succeed' '\n> +\t(\n> +\t\techo content > foo &&\n> +\t\tgit add foo &&\n> +\t\tgit commit -m \"initial commit\"\n> +\t) &&\n> +\tcommit_msg_is \"initial commit\"\n> +'\n\nNo need for this, especially if this becomes part of t7500.\n\n> +test_expect_success 'Commit no message with --allow-empty-message' '\n> +\t(\n> +\t\techo \"more content\" >> foo &&\n> +\t\tgit add foo &&\n> +\t\tprintf \"\" | git commit --allow-empty-message\n> +\t) &&\n> +\tcommit_msg_is \"\"\n> +'\n\nNo need for subprocess, nor printf piped to the command.\n\n> +test_expect_success 'Commit a message with --allow-empty-message' '\n> +\t(\n> +\t\techo \"even more content\" >> foo &&\n> +\t\tgit add foo &&\n> +\t\tgit commit --allow-empty-message -m\"hello there\"\n> +\t) &&\n> +\tcommit_msg_is \"hello there\"\n> +'\n\nDitto.\n\nYou are falling into the same trap as everybody else does when showing off\nyour shiny new toy.  A missing but very necessary test is that \"commit\"\nwith your patch does still fail when an empty message is given without the\nnew option.\n\nIt takes a conscious effort to carefully make sure that your shiny new toy\ndoes not trigger when it shouldn't, especially when you are so excited by\nseeing it work when it should.\n\nBut that is part of the art of writing good test scripts.\n\n t/t7500-commit.sh |   22 ++++++++++++++++++++++\n 1 files changed, 22 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t7500-commit.sh b/t/t7500-commit.sh\nindex 9f5c3ed..aa9c577 100755\n--- a/t/t7500-commit.sh\n+++ b/t/t7500-commit.sh\n@@ -193,4 +193,26 @@ test_expect_success 'commit -F overrides -t' '\n \tcommit_msg_is \"-F log\"\n '\n \n+test_expect_success 'Commit without message is allowed with --allow-empty-message' '\n+\techo \"more content\" >>foo &&\n+\tgit add foo &&\n+\t>empty &&\n+\tgit commit --allow-empty-message <empty &&\n+\tcommit_msg_is \"\"\n+'\n+\n+test_expect_success 'Commit without message is no-no without --allow-empty-message' '\n+\techo \"more content\" >>foo &&\n+\tgit add foo &&\n+\t>empty &&\n+\ttest_must_fail git commit <empty\n+'\n+\n+test_expect_success 'Commit a message with --allow-empty-message' '\n+\techo \"even more content\" >>foo &&\n+\tgit add foo &&\n+\tgit commit --allow-empty-message -m\"hello there\" &&\n+\tcommit_msg_is \"hello there\"\n+'\n+\n test_done\n"},{"id":"138828","messageId":"t2u51dd1af81004070728q491ae158gd6808f6ef4165b21@mail.gmail.com","threadId":"23322","inReplyTo":"7vsk77g7um.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] Add option to git-commit to allow empty log messages","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-07T14:28:06Z","receivedAt":"2010-04-07T14:28:06Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 7, 2010 at 05:16, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> diff --git a/t/t7510-commit-allow-empty-message.sh b/t/t7510-commit-allow-empty-message.sh\n>> new file mode 100755\n>> index 0000000..d7dc0da\n>\n> I do not think a separate script is worth it.  I'd just add tests to t7500.\n>\n>> +test_expect_success 'a basic commit in an empty tree should succeed' '\n>> +     (\n>> +             echo content > foo &&\n>> +             git add foo &&\n>> +             git commit -m \"initial commit\"\n>> +     ) &&\n>> +     commit_msg_is \"initial commit\"\n>> +'\n>\n> No need for this, especially if this becomes part of t7500.\n>\n>> +test_expect_success 'Commit no message with --allow-empty-message' '\n>> +     (\n>> +             echo \"more content\" >> foo &&\n>> +             git add foo &&\n>> +             printf \"\" | git commit --allow-empty-message\n>> +     ) &&\n>> +     commit_msg_is \"\"\n>> +'\n>\n> No need for subprocess, nor printf piped to the command.\n>\n>> +test_expect_success 'Commit a message with --allow-empty-message' '\n>> +     (\n>> +             echo \"even more content\" >> foo &&\n>> +             git add foo &&\n>> +             git commit --allow-empty-message -m\"hello there\"\n>> +     ) &&\n>> +     commit_msg_is \"hello there\"\n>> +'\n>\n> Ditto.\n>\n> You are falling into the same trap as everybody else does when showing off\n> your shiny new toy.  A missing but very necessary test is that \"commit\"\n> with your patch does still fail when an empty message is given without the\n> new option.\n>\n> It takes a conscious effort to carefully make sure that your shiny new toy\n> does not trigger when it shouldn't, especially when you are so excited by\n> seeing it work when it should.\n>\n> But that is part of the art of writing good test scripts.\n\nThanks for shepherding the patch and committing it, and for pointing\nout what I could have done better. I'll try not to make similar\nmistakes with future submissions.\n"},{"id":"138842","messageId":"1270652979-23572-1-git-send-email-avarab@gmail.com","threadId":"23322","inReplyTo":"h2h51dd1af81004060142p25194aaai58492f617419d0f8@mail.gmail.com","subject":"[PATCH] Remove --allow-empty from the git-commit synopsis","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-07T15:09:39Z","receivedAt":"2010-04-07T15:09:39Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"The --allow-empty option is too rarley used to warrant being displayed\nin the SYNOPSIS. It should only be mentioned in the main body of the\ndocumentation like --porcelain.\n\nThe issue was raised in the thread discussing the new\n--allow-empty-message option (see 1aadbfad) by Jeff King\n<peff@peff.net>:\n\n    http://marc.info/?l=git&m=127054334121604\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n Documentation/git-commit.txt |    5 ++---\n 1 files changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 64fb458..ed2cd95 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -10,9 +10,8 @@ SYNOPSIS\n [verse]\n 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]\n \t   [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]\n-\t   [--allow-empty] [--no-verify] [-e] [--author=<author>]\n-\t   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]\n-\t   [[-i | -o ]<file>...]\n+\t   [--no-verify] [-e] [--author=<author>] [--date=<date>]\n+\t   [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...]\n \n DESCRIPTION\n -----------\n-- \n1.7.0.4.298.gc81d\n"},{"id":"138844","messageId":"w2zfabb9a1e1004070829ob9da47e6oacf2703129be9107@mail.gmail.com","threadId":"23322","inReplyTo":"1270652979-23572-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH] Remove --allow-empty from the git-commit synopsis","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-07T15:29:56Z","receivedAt":"2010-04-07T15:29:56Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Apr 7, 2010 at 10:09, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> --allow-empty-message option (see 1aadbfad) by Jeff King\n\nThe hash of that commit is likely to change before it is included, so\nI'm not sure if it's wise to include it here right now, unless Junio\nis willing to make sure this reference stays correct?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"138861","messageId":"1270661327-28078-1-git-send-email-avarab@gmail.com","threadId":"23322","inReplyTo":"w2zfabb9a1e1004070829ob9da47e6oacf2703129be9107@mail.gmail.com","subject":"[PATCH v2] Remove --allow-empty from the git-commit synopsis","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-07T17:28:47Z","receivedAt":"2010-04-07T17:28:47Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"The --allow-empty option is too rarley used to warrant being displayed\nin the SYNOPSIS. It should only be mentioned in the main body of the\ndocumentation like --porcelain.\n\nThe issue was raised in the thread discussing the new\n--allow-empty-message option by Jeff King <peff@peff.net>:\n\n    http://marc.info/?l=git&m=127039258902941\n    http://marc.info/?l=git&m=127054334121604\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\nI'd forgotten how the Git project likes rebasing :)\n\nHere's a better patch that just cites the two relevant mailing list\nposts instead of the commit sha1.\n\n Documentation/git-commit.txt |    5 ++---\n 1 files changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 64fb458..ed2cd95 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -10,9 +10,8 @@ SYNOPSIS\n [verse]\n 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]\n \t   [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]\n-\t   [--allow-empty] [--no-verify] [-e] [--author=<author>]\n-\t   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]\n-\t   [[-i | -o ]<file>...]\n+\t   [--no-verify] [-e] [--author=<author>] [--date=<date>]\n+\t   [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...]\n \n DESCRIPTION\n -----------\n-- \n1.7.0.4.298.gc81d\n"},{"id":"138863","messageId":"o2zfabb9a1e1004071052g24f91df2ra15f0c517bdd4887@mail.gmail.com","threadId":"23322","inReplyTo":"1270661327-28078-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH v2] Remove --allow-empty from the git-commit synopsis","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-07T17:52:52Z","receivedAt":"2010-04-07T17:52:52Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Apr 7, 2010 at 12:28, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> I'd forgotten how the Git project likes rebasing :)\n\nIt's not so much the rebasing, but your patch gets applied manually\nfrom the mbox (meaning a different timestamp) by Junio (meaning a\ndifferent committer), who adds his S-o-b (meaning a different commit\nmessage), so yeah, the hash is gonna change ;).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"138866","messageId":"r2n51dd1af81004071117gcc3359dcg1b7d9f034d4b1e16@mail.gmail.com","threadId":"23322","inReplyTo":"o2zfabb9a1e1004071052g24f91df2ra15f0c517bdd4887@mail.gmail.com","subject":"Re: [PATCH v2] Remove --allow-empty from the git-commit synopsis","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-07T18:17:47Z","receivedAt":"2010-04-07T18:17:47Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 7, 2010 at 17:52, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> Heya,\n>\n> On Wed, Apr 7, 2010 at 12:28, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>> I'd forgotten how the Git project likes rebasing :)\n>\n> It's not so much the rebasing, but your patch gets applied manually\n> from the mbox (meaning a different timestamp) by Junio (meaning a\n> different committer), who adds his S-o-b (meaning a different commit\n> message), so yeah, the hash is gonna change ;).\n\nOf course, but in this case the patch had already been pushed by Junio\nto the Git repository as 1aadbf, my original commit was 1eb6f8. The\nSHA1 wouldn't change when it was cherry-picked to master unless it was\nfurther rewritten.\n\nBut in any case referencing the mailing list post instead of the SHA1 is better.\n"},{"id":"138867","messageId":"v2ybe6fef0d1004071121gcdd530dcvaaed78c0b989fc99@mail.gmail.com","threadId":"23322","inReplyTo":"1270661327-28078-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH v2] Remove --allow-empty from the git-commit synopsis","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-04-07T18:21:42Z","receivedAt":"2010-04-07T18:21:42Z","isPatch":true,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Thu, Apr 8, 2010 at 1:28 AM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> The --allow-empty option is too rarley used to warrant being displayed\n\ns/rarley/rarely/\n\n-- \nCheers,\nRay Chuan\n"},{"id":"138874","messageId":"1270666132-29430-1-git-send-email-avarab@gmail.com","threadId":"23322","inReplyTo":"v2ybe6fef0d1004071121gcdd530dcvaaed78c0b989fc99@mail.gmail.com","subject":"[PATCH v3] Remove --allow-empty from the git-commit synopsis","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-07T18:48:52Z","receivedAt":"2010-04-07T18:48:52Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"The --allow-empty option is too rarely used to warrant being displayed\nin the SYNOPSIS. It should only be mentioned in the main body of the\ndocumentation like --porcelain.\n\nThe issue was raised in the thread discussing the new\n--allow-empty-message option by Jeff King <peff@peff.net>:\n\n    http://marc.info/?l=git&m=127039258902941\n    http://marc.info/?l=git&m=127054334121604\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\nThanks for catching that. Here's the commit without the tyop :)\n\n Documentation/git-commit.txt |    5 ++---\n 1 files changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 64fb458..ed2cd95 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -10,9 +10,8 @@ SYNOPSIS\n [verse]\n 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]\n \t   [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]\n-\t   [--allow-empty] [--no-verify] [-e] [--author=<author>]\n-\t   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]\n-\t   [[-i | -o ]<file>...]\n+\t   [--no-verify] [-e] [--author=<author>] [--date=<date>]\n+\t   [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...]\n \n DESCRIPTION\n -----------\n-- \n1.7.0.4.298.gc81d\n"},{"id":"138876","messageId":"201004072055.30017.j6t@kdbg.org","threadId":"23322","inReplyTo":"1270661327-28078-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH v2] Remove --allow-empty from the git-commit synopsis","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-04-07T18:55:29Z","receivedAt":"2010-04-07T18:55:29Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Mittwoch, 7. April 2010, Ævar Arnfjörð Bjarmason wrote:\n> --- a/Documentation/git-commit.txt\n> +++ b/Documentation/git-commit.txt\n> @@ -10,9 +10,8 @@ SYNOPSIS\n>  [verse]\n>  'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]\n> [--dry-run] [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]\n> -\t   [--allow-empty] [--no-verify] [-e] [--author=<author>]\n> -\t   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]\n> -\t   [[-i | -o ]<file>...]\n> +\t   [--no-verify] [-e] [--author=<author>] [--date=<date>]\n> +\t   [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...]\n\nIMO the option should not be removed from the synopsis section of the \ndocumentation. I would agree that it is removed from the output of 'git \ncommit -h', and I think this was the original intent when someone (Junio?) \nsuggested to remove it.\n\n-- Hannes\n"},{"id":"138877","messageId":"7vfx37cckf.fsf@alter.siamese.dyndns.org","threadId":"23322","inReplyTo":"1270661327-28078-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH v2] Remove --allow-empty from the git-commit synopsis","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-07T19:00:48Z","receivedAt":"2010-04-07T19:00:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:\n\n> The --allow-empty option is too rarley used to warrant being displayed\n> in the SYNOPSIS. It should only be mentioned in the main body of the\n> documentation like --porcelain.\n>\n> The issue was raised in the thread discussing the new\n> --allow-empty-message option by Jeff King <peff@peff.net>:\n\nIf you mention what Peff said, it would be nice to Cc: him.\n\n>     http://marc.info/?l=git&m=127039258902941\n>     http://marc.info/?l=git&m=127054334121604\n\nPlease don't cite marc, especially when you refer to a thread or a patch.\nTheir interface, even in the \"raw\" mode, does not give the message headers\n(presumably by design, in order to block e-mail address harvesters) that\nmakes it unusable to get patches out of for applying.\n\nGiving a message-ID would be vendor neutral and a useful alternative\ninstead, like so:\n\n    Message-ID: <20100406055530.GE3901@coredump.intra.peff.net>\n\nThen people can paste it after \"http://mid.gmane.org/\" or feed it to their\nfavourite MUA.\n\n>  Documentation/git-commit.txt |    5 ++---\n>  1 files changed, 2 insertions(+), 3 deletions(-)\n>\n> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\n> index 64fb458..ed2cd95 100644\n> --- a/Documentation/git-commit.txt\n> +++ b/Documentation/git-commit.txt\n> @@ -10,9 +10,8 @@ SYNOPSIS\n>  [verse]\n>  'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]\n>  \t   [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]\n> -\t   [--allow-empty] [--no-verify] [-e] [--author=<author>]\n> -\t   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]\n> -\t   [[-i | -o ]<file>...]\n> +\t   [--no-verify] [-e] [--author=<author>] [--date=<date>]\n> +\t   [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...]\n\nI do not think Jeff was against having a complete listing in the\ndocumentation.  Wasn't his suggestion about \"git commit -h\" output?\n"},{"id":"138881","messageId":"1270668498-30495-1-git-send-email-avarab@gmail.com","threadId":"23322","inReplyTo":"7vfx37cckf.fsf@alter.siamese.dyndns.org","subject":"[PATCH v4] Remove --allow-empty from the git-commit synopsis","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-07T19:28:18Z","receivedAt":"2010-04-07T19:28:18Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"The --allow-empty option is too rarely used to warrant being displayed\nin the SYNOPSIS. It should only be mentioned in the main body of the\ndocumentation like --porcelain.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n\n> If you mention what Peff said, it would be nice to Cc: him.\n\nCorrected.\n\n> Please don't cite marc\n\nSorry, I'm new here and there was no mention of this in\nDocumentation/SubmittingPatches. I looked through `git log' for the\nproject and found 10 such links in other commit messages.\n\nNow that I look closer there are 14 references to some `Message-ID:',\nbut of course someone getting it wrong in the past doesn't mean that\nit's a good idea to follow their example. I won't cite marc.info\nagain.\n\n> I do not think Jeff was against having a complete listing in the\n> documentation.  Wasn't his suggestion about \"git commit -h\" output\n\nYes I misread (or rather, mis-recalled) the content of his message. He\nwas indeed talking about `git commit -h' output, but I subsequently\nupdated my --allow-empty-message patch to omit it from the SYNOPSIS\nfor git-commit(1). I've removed the links to `marc.info' (or any\nMessage-ID's) since they aren't pertinent anymore.\n\nThe relatively obscure --allow-empty* options should regardless of\nthat misunderstanding probably be omitted from the SYNOPSIS\nsection. It would reduce the cognitive load of the casual manual\nreader who's trying to get an idea of the most common usage for the\ncommand.\n\nAs for Jeff's suggestion of omitting options from the `--help' output:\nI couldn't find a way to do that using parse-options.[ch]. It's also\ncustomary for `--help' to include the full usage examples regardless\nof how long they get (just look at wget, ls etc.). The SYNOPSIS\nsections in manual pages by comparison usually aim for brevity.\n\n Documentation/git-commit.txt |    5 ++---\n 1 files changed, 2 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 64fb458..ed2cd95 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -10,9 +10,8 @@ SYNOPSIS\n [verse]\n 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]\n \t   [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]\n-\t   [--allow-empty] [--no-verify] [-e] [--author=<author>]\n-\t   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]\n-\t   [[-i | -o ]<file>...]\n+\t   [--no-verify] [-e] [--author=<author>] [--date=<date>]\n+\t   [--cleanup=<mode>] [--status | --no-status] [--] [[-i | -o ]<file>...]\n \n DESCRIPTION\n -----------\n-- \n1.7.0.4.298.gc81d\n"},{"id":"138884","messageId":"j2s780e0a6b1004071245jaaaf8d20r71720749c29227b8@mail.gmail.com","threadId":"23322","inReplyTo":"1270668498-30495-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH v4] Remove --allow-empty from the git-commit synopsis","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2010-04-07T19:45:48Z","receivedAt":"2010-04-07T19:45:48Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On Wed, Apr 7, 2010 at 12:28 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n>\n> As for Jeff's suggestion of omitting options from the `--help' output:\n> I couldn't find a way to do that using parse-options.[ch]. It's also\n> customary for `--help' to include the full usage examples regardless\n> of how long they get (just look at wget, ls etc.). The SYNOPSIS\n> sections in manual pages by comparison usually aim for brevity.\n>\n\nYou can hide options from the -h output (not --help-all) by using the\nPARSE_OPT_HIDDEN flag.\n"},{"id":"138900","messageId":"7vbpduc333.fsf@alter.siamese.dyndns.org","threadId":"23322","inReplyTo":"7vfx37cckf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] Remove --allow-empty from the git-commit synopsis","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-07T22:25:36Z","receivedAt":"2010-04-07T22:25:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I do not think Jeff was against having a complete listing in the\n> documentation.  Wasn't his suggestion about \"git commit -h\" output?\n\nI'll amend the earlier \"allow-empty-message\" one from you to cover this\ntopic.\n\n-- >8 --\nFrom: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\nDate: Tue, 6 Apr 2010 08:40:35 +0000\nSubject: [PATCH] Add option to git-commit to allow empty log messages\n\nChange git-commit(1) to accept the --allow-empty-message option\nto allow a commit with an empty message.  This is analogous to the\nexisting --allow-empty option which allows a commit that records\nno changes.  As these are mainly for interoperating with foreign SCM\nsystems, and are not meant for normal use, ensure that \"git commit -h\"\ndoes not talk about them.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Documentation/git-commit.txt |    8 +++++++-\n builtin/commit.c             |   12 +++++++++---\n t/t7500-commit.sh            |   22 ++++++++++++++++++++++\n 3 files changed, 38 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 64fb458..32c482f 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -10,7 +10,7 @@ SYNOPSIS\n [verse]\n 'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]\n \t   [(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]\n-\t   [--allow-empty] [--no-verify] [-e] [--author=<author>]\n+\t   [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>]\n \t   [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]\n \t   [[-i | -o ]<file>...]\n \n@@ -131,6 +131,12 @@ OPTIONS\n \tfrom making such a commit.  This option bypasses the safety, and\n \tis primarily for use by foreign scm interface scripts.\n \n+--allow-empty-message::\n+       Like --allow-empty this command is primarily for use by foreign\n+       scm interface scripts. It allows you to create a commit with an\n+       empty commit message without using plumbing commands like\n+       linkgit:git-commit-tree[1].\n+\n --cleanup=<mode>::\n \tThis option sets how the commit message is cleaned up.\n \tThe  '<mode>' can be one of 'verbatim', 'whitespace', 'strip',\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex c5ab683..821a49d 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -66,7 +66,7 @@ static char *edit_message, *use_message;\n static char *author_name, *author_email, *author_date;\n static int all, edit_flag, also, interactive, only, amend, signoff;\n static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;\n-static int no_post_rewrite;\n+static int no_post_rewrite, allow_empty_message;\n static char *untracked_files_arg, *force_date;\n /*\n  * The default commit message cleanup mode will remove the lines\n@@ -140,9 +140,15 @@ static struct option builtin_commit_options[] = {\n \tOPT_BOOLEAN(0, \"amend\", &amend, \"amend previous commit\"),\n \tOPT_BOOLEAN(0, \"no-post-rewrite\", &no_post_rewrite, \"bypass post-rewrite hook\"),\n \t{ OPTION_STRING, 'u', \"untracked-files\", &untracked_files_arg, \"mode\", \"show untracked files, optional modes: all, normal, no. (Default: all)\", PARSE_OPT_OPTARG, NULL, (intptr_t)\"all\" },\n-\tOPT_BOOLEAN(0, \"allow-empty\", &allow_empty, \"ok to record an empty change\"),\n \t/* end commit contents options */\n \n+\t{ OPTION_BOOLEAN, 0, \"allow-empty\", &allow_empty, NULL,\n+\t  \"ok to record an empty change\",\n+\t  PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },\n+\t{ OPTION_BOOLEAN, 0, \"allow-empty-message\", &allow_empty_message, NULL,\n+\t  \"ok to record a change with an empty message\",\n+\t  PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },\n+\n \tOPT_END()\n };\n \n@@ -1293,7 +1299,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \n \tif (cleanup_mode != CLEANUP_NONE)\n \t\tstripspace(&sb, cleanup_mode == CLEANUP_ALL);\n-\tif (message_is_empty(&sb)) {\n+\tif (message_is_empty(&sb) && !allow_empty_message) {\n \t\trollback_index_files();\n \t\tfprintf(stderr, \"Aborting commit due to empty commit message.\\n\");\n \t\texit(1);\ndiff --git a/t/t7500-commit.sh b/t/t7500-commit.sh\nindex 9f5c3ed..aa9c577 100755\n--- a/t/t7500-commit.sh\n+++ b/t/t7500-commit.sh\n@@ -193,4 +193,26 @@ test_expect_success 'commit -F overrides -t' '\n \tcommit_msg_is \"-F log\"\n '\n \n+test_expect_success 'Commit without message is allowed with --allow-empty-message' '\n+\techo \"more content\" >>foo &&\n+\tgit add foo &&\n+\t>empty &&\n+\tgit commit --allow-empty-message <empty &&\n+\tcommit_msg_is \"\"\n+'\n+\n+test_expect_success 'Commit without message is no-no without --allow-empty-message' '\n+\techo \"more content\" >>foo &&\n+\tgit add foo &&\n+\t>empty &&\n+\ttest_must_fail git commit <empty\n+'\n+\n+test_expect_success 'Commit a message with --allow-empty-message' '\n+\techo \"even more content\" >>foo &&\n+\tgit add foo &&\n+\tgit commit --allow-empty-message -m\"hello there\" &&\n+\tcommit_msg_is \"hello there\"\n+'\n+\n test_done\n-- \n1.7.1.rc0.212.gbd88f\n"},{"id":"138935","messageId":"20100408064450.GE30473@coredump.intra.peff.net","threadId":"23322","inReplyTo":"7vbpduc333.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] Remove --allow-empty from the git-commit synopsis","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-08T06:44:50Z","receivedAt":"2010-04-08T06:44:50Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 07, 2010 at 03:25:36PM -0700, Junio C Hamano wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > I do not think Jeff was against having a complete listing in the\n> > documentation.  Wasn't his suggestion about \"git commit -h\" output?\n> \n> I'll amend the earlier \"allow-empty-message\" one from you to cover this\n> topic.\n\nMy suggestion was for \"git commit -h\", and your amended patch addresses\nit. Thanks.\n\nFor the record, I am _also_ against having a complete listing at the\nheader of the documentation, but last time this was discussed some\nothers felt differently, and I don't think we reached a consensus on\nwhat the manpages should look like (right now some have a very terse\nsynopsis, and some try to list every option).\n\n-Peff\n"}]}