The gray color for 'git:(' ')' which surrounds the branch information in
the default prompt was originally chosen for its appearance in the macos
terminal, which I believe renders bold colors as bright.  My own
terminal emulator also renders bold colors this way.

"Bold bright black" is the intended color for this value, but on many
other terminals it appears as a very dark and unreadable bit of text.
So make the correct color explicit by using black from the bright range
of colors (90).

Signed-off-by: Matt Hunter <m@lfurio.us>

Add GIT_SONAR_COLOR_PREFIX and GIT_SONAR_COLOR_SUFFIX, which control the
shell prompt unprintable character markers used by default color codes
in git-sonar.  These are added as a convenience so that a user on zsh,
for example, doesn't need to redefine every color setting when the only
thing they need to replace is the \001 and \002.

This is similar to the old shell options (--bash, --zsh, --fish) from
git-radar, but is open-ended so that the user may configure exactly what
is needed for any old shell, without the need to teach git-sonar
specific details in advance.  See also c4da5e91d053 ("Merge
bash/zsh/fish color modes together").

Signed-off-by: Matt Hunter <m@lfurio.us>

Signed-off-by: Matt Hunter <m@lfurio.us>

Add an additional config variable 'GIT_SONAR_DETACHED_COLOR', which is
used to color the %{branch} element when on a detached HEAD.  Both
"branch color" and "detached color" default to uncolored, but may now be
configured independently.

Signed-off-by: Matt Hunter <m@lfurio.us>

I found the original context behind why git-radar had custom color reset
codes.  It sums up to playing more nicely with a background color, such
as something used in a "power line" style prompt.  This use-case makes
sense, so re-introduce a config variable to control this.

We still don't need an individual reset value for each prompt element,
so keep it to the single general one, defaulted to \033[0m.

Link: https://github.com/michaeldfallen/git-radar/issues/14
Signed-off-by: Matt Hunter <m@lfurio.us>

There are some contexts/shells in which the extra escape character is
necessary, so fixup the color constants in git-sonar.  Doing so doesn't
break any current use-cases.

User overrides may or may not need to do the same.

Signed-off-by: Matt Hunter <m@lfurio.us>

Signed-off-by: Matt Hunter <m@lfurio.us>

After a bisect session begins and up until the first 'bad' and 'good'
revisions are identified, BISECT_EXPECTED_REV is undefined, and the
freshly started session goes undetected by git-precheck.

Among a few potential alternatives, BISECT_START is a better signal, as
it covers this gap and exists for the entire duration of a session -
from 'git bisect start' to 'git bisect reset'.

The file-based detection paradigm makes this choice more obvious.

Signed-off-by: Matt Hunter <m@lfurio.us>

Signed-off-by: Matt Hunter <m@lfurio.us>

Detect all ongoing git conditions by checking for the existence of some
file or directory within the .git folder.  This eliminates the previous
git rev-parse --verify commands, which should be a slight boost to
performance.  Furthermore, the implementation of rebase detection is no
longer a special case.

Also, restructure the script such that all applicable conditions are
reported when run, not just the first we detect.  The script exit code
reflects the highest value of the active conditions.  Though, as an
optimization, still exit on the first found when --quiet is in effect.

The script is cleaned up as well.  In some cases style is changed to
better match the current state of git-sonar.  git-status is now only
called once and cached for both dirty and untracked detection.

Signed-off-by: Matt Hunter <m@lfurio.us>