* nd/status-auto-comment-char:
  commit: allow core.commentChar=auto for character auto selection
  config: be strict on core.commentChar

* fc/status-printf-squelch-format-zero-length-warnings:
  silence a bunch of format-zero-length warnings

"git commit --allow-empty-message -C $commit" did not work when the
commit did not have any log message.

* jk/commit-C-pick-empty:
  commit: do not complain of empty messages from -C

* jk/commit-date-approxidate:
  commit: accept more date formats for "--date"
  commit: print "Date" line when the user has set date
  pretty: make show_ident_date public
  commit: use split_ident_line to compare author/committer

When core.commentChar is "auto", the comment char starts with '#' as
in default but if it's already in the prepared message, find another
char in a small subset. This should stop surprises because git strips
some lines unexpectedly.

Note that git is not smart enough to recognize '#' as the comment char
in custom templates and convert it if the final comment char is
different. It thinks '#' lines in custom templates as part of the
commit message. So don't use this with custom templates.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

This can be observed in many versions of gcc and still exists with 4.9.0:

  wt-status.c: In function ‘wt_status_print_unmerged_header’:
  wt-status.c:191:2: warning: zero-length gnu_printf format string [-Wformat-zero-length]
    status_printf_ln(s, c, "");
    ^

The user have long been told to pass -Wno-format-zero-length, but a
patch that avoids warning altogether is not too noisy, so let's do
so.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Right now we pass off the string found by "--date" straight
to the fmt_ident function, which will use our strict
parse_date to normalize it. However, this means obvious
things like "--date=now" or "--date=2.days.ago" will not
work.

Instead, let's fallback to the approxidate function to
handle this for us. Note that we must try parse_date
ourselves first, even though approxidate will try strict
parsing itself. The reason is that approxidate throws away
any timezone information it sees from the strict parsing,
and we want to preserve it. So asking for:

  git commit --date="@1234567890 -0700"

continues to set the date in -0700, regardless of what the
local timezone is.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

When we make a commit and the author is not the same as the
committer (e.g., because you used "-c $commit" or
"--author=$somebody"), we print the author's name and email
in both the commit-message template and as part of the
commit summary. This is a safety check to give the user a
chance to confirm that we are doing what they expect.

This patch brings the same safety for the "date" field,
which may be set by "-c" or by using "--date".  Note that we
explicitly do not set it for $GIT_AUTHOR_DATE, as it is
probably not of interest when "git commit" is being fed its
parameters by a script.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Instead of string-wise comparing the author/committer lines
with their timestamps truncated, we can use split_ident_line
and ident_cmp. These functions are more robust than our
ad-hoc parsing, though in practice it should not matter, as
we just generated these ident lines ourselves.

However, this will also allow us easy access to the
timestamp and tz fields in future patches.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

When we pick another commit's message, we die() immediately
if we find that it's empty and we are not going to run an
editor (i.e., when running "-C" instead of "-c").  However,
this check is redundant and harmful.

It's redundant because we will already notice the empty
message later, after we would have run the editor, and die
there (just as we would for a regular, not "-C" case, where
the user provided an empty message in the editor).

It's harmful for a few reasons:

  1. It does not respect --allow-empty-message. As a result,
     a "git rebase -i" cannot "pick" such a commit. So you
     cannot even go back in time to fix it with a "reword"
     or "edit" instruction.

  2. It does not take into account other ways besides the
     editor to modify the message. For example, "git commit
     -C empty-commit -m foo" could take the author
     information from empty-commit, but add a message to it.
     There's more to do to make that work correctly (and
     right now we explicitly forbid "-C with -m"), but this
     removes one roadblock.

  3. The existing check is not enough to prevent segfaults.
     We try to find the "\n\n" header/body boundary in the
     commit. If it is at the end of the string (i.e., no
     body), _or_ if we cannot find it at all (i.e., a
     truncated commit object), we consider the message
     empty. With "-C", that's OK; we die in either case. But
     with "-c", we continue on, and in the case of a
     truncated commit may end up dereferencing NULL+2.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>