Allow __git_ps1 to be used in PROMPT_COMMAND

Changes __git_ps1 to allow its use as PROMPT_COMMAND in bash
in addition to setting PS1 with __git_ps1 in a command substitution.
PROMPT_COMMAND has advantages for using color without running
into prompt-wrapping issues. Only by assigning \[ and \] to PS1
directly can bash know that these and the enclosed zero-width codes in
between don't count in the length of the prompt.

Signed-off-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
show color hints based on state of the git tree

By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1
as PROMPT_COMMAND, you will get color hints in addition to
a different character (*+% etc.) to indicate the state of
the tree.

Signed-off-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix up colored git-prompt

The main point is to match the colors to be more close to the color
output of "git status -sb".

 - the branchname is green, or in red when the HEAD is detached;

 - the flags are either red or green for unstaged/staged and the
   remaining flags get a different color or none at all.

Signed-off-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Split over-long synopsis in git-fetch-pack.txt into several lines

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/technical: convert plain text files to asciidoc

These were not originally meant for asciidoc, but they are already
so close.  Mark them up in asciidoc.

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-cvsimport: allow author-specific timezones

CVS patchsets are imported with timestamps having an offset of +0000
(UTC).  The cvs-authors file is already used to translate the CVS
username to full name and email in the corresponding commit.  Extend
this file to support an optional timezone for calculating a user-
specific timestamp offset.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
coloured git-prompt: paint detached HEAD marker in red

Paint the marker for normal state in green and detached state
in red, instead of the other way around.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix "git diff --stat" for interesting - but empty - file changes

The behavior of "git diff --stat" is rather odd for files that have
zero lines of changes: it will discount them entirely unless they were
renames.

Which means that the stat output will simply not show files that only
had "other" changes: they were created or deleted, or their mode was
changed.

Now, those changes do show up in the summary, but so do renames, so
the diffstat logic is inconsistent. Why does it show renames with zero
lines changed, but not mode changes or added files with zero lines
changed?

So change the logic to not check for "is_renamed", but for
"is_interesting" instead, where "interesting" is judged to be any
action but a pure data change (because a pure data change with zero
data changed really isn't worth showing, if we ever get one in our
diffpairs).

So if you did

   chmod +x Makefile
   git diff --stat

before, it would show empty (" 0 files changed"), with this it shows

 Makefile | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

which I think is a more correct diffstat (and then with "--summary" it
shows *what* the metadata change to Makefile was - this is completely
consistent with our handling of renamed files).

Side note: the old behavior was *really* odd. With no changes at all,
"git diff --stat" output was empty. With just a chmod, it said "0
files changed". No way is our legacy behavior sane.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty: remove reencode_commit_message()

This function has only two callsites, and is a thin wrapper whose
usefulness is dubious.  When the caller needs to learn the log
output encoding, it should be able to do so by directly calling
get_log_output_encoding() and calling the underlying
logmsg_reencode() with it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
format_note(): simplify API

We either stuff the notes message without modification for %N
userformat, or format it for human consumption.  Using two bits
is an overkill that does not benefit anybody.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty: prepare notes message at a centralized place

Instead of passing a boolean show_notes around, pass an optional
string that is to be inserted after the log message proper is shown.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty_print_commit(): do not append notes message

The only case pretty_print_commit() appends notes message to the log
message taken from the commit is when show_log() calls it with the
notes_message field set, and the output format is not the userformat
(i.e. when substituting "%N").  No other users of this function sets
this field in the pretty_print_context, as can be easily verified in
the previous step.

Hoist the code to append the notes message to the caller.

Up to this point, no functionality change is intended.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
format-patch: append --signature after notes

When appending a new signature with "format-patch --signature", if
the "--notes" option is also in effect, the location of the new
signature (and if the signature should be added in the first place)
should be decided using the contents of the original commit log
message, before the message from the notes is added.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
format-patch --notes: show notes after three-dashes

When inserting the note after the commit log message to format-patch
output, add three dashes before the note.  Record the fact that we
did so in the rev_info and omit showing duplicated three dashes in
the usual codepath that is used when notes are not being shown.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/howto: convert plain text files to asciidoc

These were not originally meant for asciidoc, but they are already
so close.  Mark them up in asciidoc.

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: decribe format-patch --notes

Even though I coded this, I am not sure what use scenarios would benefit
from this option, so the description is unnecessarily negative at this
moment. People who do want to use this feature need to come up with a
more plausible use case and replace it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
get_fetch_map(): tighten checks on dest refs

The code to check the refname we store the fetched result locally did not
bother checking the first 5 bytes of it, presumably assuming that it
always begin with "refs/".  For a fetch refspec (or the result of applying
wildcard on one), we always want the RHS to map to something inside
"refs/" hierarchy, so let's spell that rule out in a more explicit way.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()

When deleting a ref through a symref (e.g. using 'git update-ref -d HEAD'
to delete refs/heads/master), we currently fail to remove the packed
version of that ref. This testcase demonstrates the bug.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>