parse_color: drop COLOR_BACKGROUND macro

Commit 695d95d (parse_color: refactor color storage,
2014-11-20) introduced two macros, COLOR_FOREGROUND and
COLOR_BACKGROUND. The latter conflicts with a system macro
defined in Windows, breaking compilation there.

The simplest solution is to just get rid of these macros
entirely. They are constants that are only used in one place
(since the whole point of the 695d95d was to avoid repeating
ourselves). Their main function is to make the magic
character constants more readable, but we can do the same
thing with a comment.
parse_color: drop COLOR_BACKGROUND macro

Commit 695d95d (parse_color: refactor color storage,
2014-11-20) introduced two macros, COLOR_FOREGROUND and
COLOR_BACKGROUND. The latter conflicts with a system macro
defined on Windows, breaking compilation there.

The simplest solution is to just get rid of these macros
entirely. They are constants that are only used in one place
(since the whole point of 695d95d was to avoid repeating
ourselves). Their main function is to make the magic
character constants more readable, but we can do the same
thing with a comment.

Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/colors' into next

* jk/colors:
  parse_color: drop COLOR_BACKGROUND macro
pkt-line: allow writing of LARGE_PACKET_MAX buffers

When we send out pkt-lines with refnames, we use a static
1000-byte buffer. This means that the maximum size of a ref
over the git protocol is around 950 bytes (the exact size
depends on the protocol line being written, but figure on a sha1
plus some boilerplate).

This is enough for any sane workflow, but occasionally odd
things happen (e.g., a bug may create a ref "foo/foo/foo/..."
accidentally).  With the current code, you cannot even use
"push" to delete such a ref from a remote.

Let's switch to using a strbuf, with a hard-limit of
LARGE_PACKET_MAX (which is specified by the protocol).  This
matches the size of the readers, as of 74543a0 (pkt-line:
provide a LARGE_PACKET_MAX static buffer, 2013-02-20).
Versions of git older than that will complain about our
large packets, but it's really no worse than the current
behavior. Right now the sender barfs with "impossibly long
line" trying to send the packet, and afterwards the reader
will barf with "protocol error: bad line length %d", which
is arguably better anyway.

Note that we're not really _solving_ the problem here, but
just bumping the limits. In theory, the length of a ref is
unbounded, and pkt-line can only represent sizes up to
65531 bytes. So we are just bumping the limit, not removing
it.  But hopefully 64K should be enough for anyone.

As a bonus, by using a strbuf for the formatting we can
eliminate an unnecessary copy in format_buf_write.
read_packed_refs: use a strbuf for reading lines

We currently used a fixed PATH_MAX-sized buffer for reading
packed-refs lines. This is a reasonable guess, in the sense
that git generally cannot work with refs larger than
PATH_MAX. However, there are a few cases where it is not
great:

  1. Some systems may have a low value of PATH_MAX, but can
     actually handle larger paths in practice. Fixing this
     code path probably isn't enough to make them work
     completely with long refs, but it is a step in the
     right direction.

  2. We use fgets, which will happily give us half a line on
     the first read, and then the rest of the line on the
     second. This is probably OK in practice, because our
     refline parser is careful enough to look for the
     trailing newline on the first line. The second line may
     look like a peeled line to us, but since "^" is illegal
     in refnames, it is not likely to come up.

     Still, it does not hurt to be more careful.
read_packed_refs: pass strbuf to parse_ref_line

Now that we have a strbuf in read_packed_refs, we can pass
it straight to the line parser, which saves us an extra
strlen.
read_packed_refs: use skip_prefix instead of static array

We want to recognize the packed-refs header and skip to the
"traits" part of the line. We currently do it by feeding
sizeof() a static const array to strncmp. However, it's a
bit simpler to just skip_prefix, which expresses the
intention more directly, and without remembering to account
for the NUL-terminator in each sizeof() call.
commit: loosen ident checks when generating template

When we generate the commit-message template, we try to
report an author or committer ident that will be of interest
to the user: an author that does not match the committer, or
a committer that was auto-configured.

When doing so, if we encounter what we consider to be a
bogus ident, we immediately die. This is a bad idea, because
our use of the idents here is purely informational.  Any
ident rules should be enforced elsewhere, because commits
that do not invoke the editor will not even hit this code
path (e.g., "git commit -mfoo" would work, but "git commit"
would not). So at best, we are redundant with other checks,
and at worse, we actively prevent commits that should
otherwise be allowed.

We should therefore do the minimal parsing we can to get a
value and not do any validation (i.e., drop the call to
sane_ident_split()).

In theory we could notice when even our minimal parsing
fails to work, and do the sane thing for each check (e.g.,
if we have an author but can't parse the committer, assume
they are different and print the author). But we can
actually simplify this even further.

We know that the author and committer strings we are parsing
have been generated earlier in the program, and therefore
they _must_ be parseable. We could just call
split_ident_line without even checking its return value,
knowing that it will _something_ in the name/mail fields. Of
course, to protect ourselves against future changes to the
code, it makes sense to turn this into an assert, so we are
not surprised if our assumption fails.
commit: always populate GIT_AUTHOR_* variables

To figure out the author ident for a commit, we call
determine_author_info(). This function collects information
from the environment, other commits (in the case of
"--amend" or "-c/-C"), and the "--author" option. It then
uses fmt_ident to generate the final ident string that goes
into the commit object. fmt_ident is therefore responsible
for any quality or validation checks on what is allowed to
go into a commit.

Before returning, though, we call split_ident_line on the
result, and feed the individual components to hooks via the
GIT_AUTHOR_* variables. Furthermore, we do extra validation
by feeding the split to sane_ident_split(), which is pickier
than fmt_ident (in particular, it will complain about an empty
email field).  If this parsing or validation fails, we skip
updating the environment variables.

This is bad, because it means that hooks may silently see a
different ident than what we are putting into the commit. We
should drop the extra sane_ident_split checks entirely, and
take whatever fmt_ident has fed us (and what will go into
the commit object).

If parsing fails, we should actually abort here rather than
continuing (and feeding the hooks bogus data). However,
split_ident_line should never fail here. The ident was just
generated by fmt_ident, so we know that it's sane. We can
use assert_split_ident to double-check this.

Note that we also teach that assertion to check that we
found a date (it always should, but until now, no caller
cared whether we found a date or not). Checking the return
value of sane_ident_split is enough to ensure we have the
name/email pointers set, and checking date_begin is enough
to know that all of the date/tz variables are set.
Merge branch 'jk/approxidate-iso-future' into HEAD

* jk/approxidate-iso-future:
  approxidate: allow ISO-like dates far in the future
  pass TIME_DATE_NOW to approxidate future-check
Merge branch 'jk/archive-reachability' into HEAD

* jk/archive-reachability:
  t5000: drop tag to supposedly unreachable object
  archive: ignore blob objects when checking reachability
  list-objects: optimize "revs->blob_objects = 0" case
  upload-archive: restrict remote objects with reachability check
Merge branch 'jk/author-no-email' into HEAD

* jk/author-no-email:
  commit: always populate GIT_AUTHOR_* variables
  commit: loosen ident checks when generating template
Merge branch 'jk/avoid-askpass' into HEAD

* jk/avoid-askpass:
  prompt: respect GIT_TERMINAL_PROMPT to disable terminal prompts
  credential: let helpers tell us to quit
Merge branch 'jk/bitmap-reuse-delta' into HEAD

* jk/bitmap-reuse-delta:
  preferred base reuse wip
  pack-objects: reuse deltas for thin "have" objects
  pack-bitmap: save "have" bitmap from walk
  t/perf: add perf tests for fetches from a bitmapped server
  t/perf: add infrastructure for measuring sizes
  t/perf/aggregate: factor our percent calculations
  t/perf-lib: factor boilerplate out of test_perf
Merge branch 'jk/bitmaps' into HEAD

* jk/bitmaps:
  wip -- better protection against corruption
Merge branch 'jk/blame-tree' into HEAD

* jk/blame-tree:
  add blame-tree command
  combine-diff: zero memory used for callback filepairs
  teach tree-diff a max-depth parameter
  within_depth: fix return for empty path
Merge branch 'jk/check-alternate-connectedness' into HEAD

* jk/check-alternate-connectedness:
  check_everything_connected: assume alternate ref tips are valid
  check_everything_connected: use argv_array
Merge branch 'jk/child-cleanup' into HEAD

* jk/child-cleanup:
  send-pack: kill pack-objects helper on signal or exit
Merge branch 'jk/color-rgb' into HEAD

* jk/color-rgb:
  parse_color: drop COLOR_BACKGROUND macro
  diff-highlight: allow configurable colors
  parse_color: recognize "no$foo" to clear the $foo attribute
  parse_color: refactor color storage
  t4026: test "normal" color
  config: fix parsing of "git config --get-color some.key -1"
  docs: describe ANSI 256-color mode
Merge branch 'jk/config-sources' into HEAD

* jk/config-sources:
  show sources of config options (WIP)