We generally disallow empty commits with "git commit". The output produced by the wt_status functions is generally sufficient to explain what happened. With --amend commits, however, things are a little more confusing. We would create an empty commit not if you actually have staged changes _now_, but if your staged changes match HEAD^. In this case, it is not immediately obvious why "git commit" claims no changes, but "git status" does not. Furthermore, we should point the user in the direction of git reset, which would eliminate the empty commit entirely. Signed-off-by: Jeff King <peff@xxxxxxxx> --- Another re-post from my fall cleaning. I have many more, but I'll make this the last for today. Original discussion here: http://thread.gmane.org/gmane.comp.version-control.git/147980/focus=148521 There were no objections; I think it simply got overlooked. builtin/commit.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index ddf77e4..2a106a1 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -48,6 +48,11 @@ static const char implicit_ident_advice[] = "\n" " git commit --amend --author='Your Name <you@xxxxxxxxxxx>'\n"; +static const char empty_amend_advice[] = +"You asked to amend the most recent commit, but doing so would make\n" +"it empty. You can repeat your command with --allow-empty, or you can\n" +"remove the commit entirely with \"git reset HEAD^\".\n"; + static unsigned char head_sha1[20]; static char *use_message_buffer; @@ -700,6 +705,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix, if (!commitable && !in_merge && !allow_empty && !(amend && is_a_merge(head_sha1))) { run_status(stdout, index_file, prefix, 0, s); + if (amend) + fputs(empty_amend_advice, stderr); return 0; } -- 1.7.3.1.235.gdd6c0 -- 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