Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.5.4:
  GIT 1.5.4.6
  git-shell: accept "git foo" form

Conflicts:

	GIT-VERSION-GEN
	RelNotes

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is a backport of 0a47dc11
to 'maint' to be included in 1.5.6.2 so that older server side
can accept dashless form of request when clients are updated.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It worked that way since commit 50f575fc (Tweak diff colors,
2006-06-22), but commit c1795bb0 (Unify whitespace checking, 2007-12-13)
changed it.  This patch restores the old behaviour.

Besides Linus' arguments in the log message of 50f575fc, resetting color
before printing newline is also important to keep 'git add --patch'
happy.  If the last line(s) of a file are removed, then that hunk will
end with a colored line.  However, if the newline comes before the color
reset, then the diff output will have an additional line at the end
containing only the reset sequence.  This causes trouble in
git-add--interactive.perl's parse_diff function, because @colored will
have one more element than @diff, and that last element will contain the
color reset.  The elements of these arrays will then be copied to @hunk,
but only as many as the number of elements in @diff.  As a result the
last color reset is lost and all subsequent terminal output will be
printed in color.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Rewrapped synopsis and removed wrong asterisk behind --count option;
clarified --sort=<key> description for multiple keys; documented that
for-each-ref supports not only glob patterns but also prefixes like
"refs/heads" as patterns, and that multiple patterns can be given.
Signed-off-by: NLea Wiemann <LeWiemann@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In commit da2478db "describe --always: fall back to showing an
abbreviated object name" we lost the check that skips empty entries in
the object hash table when iterating over it in cmd_name_rev. That may
cause a NULL pointer being handed to show_name(), leading to a
segmentation fault. So add that check back again.
Signed-off-by: NBjörn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The <pattern> given "git describe --match" was used only to filter tag
objects, and not to filter lightweight tags.  This fixes it.

[jc: made the log to clarify this is a bugfix, not an enhancement, with
additional test]
Signed-off-by: NMichael Dressel <MichaelTiloDressel@t-online.de>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When adding files through git commit --interactive, and 'quit'
afterwards, the message in the editor of the commit message indicates
that many (maybe all) files are deleted from the tree.  Dismissing that
and running git commit afterwards does the right thing.  This commit
fixes git commit --interactive to properly update the index before
commiting.

Reported by Jiří Paleček through
 http://bugs.debian.org/480429Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There was a bug in the implementation of the "next" links in
format_paging_nav (for log and shortlog), which caused the next links
to always be displayed, even if there is no next page.  This fixes it.
Signed-off-by: NLea Wiemann <LeWiemann@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This reverts commit cfabd6ee. I had
implemented it without understanding what --full-history does. Consider
this history:

    C--M--N
   /  /  /
  A--B  /
   \   /
    D-/

where B and C modify a path, X, in the same way so that the result is
identical, and D does not modify it at all. With the path limiter X and
without --full-history this is simplified to

   A--B

i.e. only one of the paths via B or C is chosen. I had assumed that
--full-history would keep both paths like this

    C--M
   /  /
  A--B

removing the path via D; but in fact it keeps the entire history.

Currently, git does not have the capability to simplify to this
intermediary case. However, the other extreme to keep the entire history
is not wanted either in usual cases. I think we can expect that histories
like the above are rare, and in the usual cases we want a simplified
history. So let's remove --full-history again.

(Concerning t7003, subsequent tests depend on what the test case sets up,
so we can't just back out the entire test case.)
Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The <git-rev-list args> are mandatory to git bundle create, not
optional.  The usage output of git bundle is already right on this.
Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* gp/bisect-fix:
  bisect: print an error message when "git rev-list --bisect-vars" fails
  git-bisect.sh: don't accidentally override existing branch "bisect"

Preformatted html and man pages show a mangled graph, caused by a
backslash.

Commit f1ec6b22 fixed this same issue,
but it seems that new versions of the Asciidoc toolchain changed their
behaviour.
Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The code assumed that there always is the current branch, but the result
from resolve_ref() on detached HEAD does not even start with "refs/heads/".

Originally noticed and fixed by Stephan Beyer.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jk/maint-send-email-compose:
  send-email: rfc2047-quote subject lines with non-ascii characters
  send-email: specify content-type of --compose body

* hb/maint-send-email-quote-recipients:
  Fix recipient santitization

* maint-1.5.4:
  builtin-fast-export: Only output a single parent per line

According to the git-fast-import man-page, you can only put a single
committish per merge: line, like this:

  merge :10
  merge :11

However, git-fast-export puts all parents on a single line, like this:

  merge :10 :11

This changes fast-export to output a single parent per line.  Otherwise
neither git-fast-import nor bzr-fast-import can read its output.

[jc: fix-up to remove excess LF in the output that makes fast-import barf]
Signed-off-by: NPieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.5.4:
  rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref

The intention of --symbolic-full-name is to not print anything if a
revision is not an exact ref. But this command:

    $ git-rev-parse --symbolic-full-name --not master~1

still emitted a sole '^' to stdout (provided that there's no other ref at
master~1). This fixes it.
Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NHeikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJon Loeliger <jdl@freescale.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

While repacking a local repository a coworker thought the -n option
was necessary to git-repack to keep it from updating some unknown
file on the central server we all share.  Explaining further what
the option is (not) doing helps to make it clear the option does
not impact any remote repositories the user may have configured.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.5.4:
  git-am: fix typo in usage message
  doc/git-daemon: s/uploadarchive/uploadarch/

Need to quote all special characters, not just the first one
Signed-off-by: NHorst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We always use 'utf-8' as the encoding, since we currently
have no way of getting the information from the user.

This also refactors the quoting of recipient names, since
both processes can share the rfc2047 quoting code.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If the compose message contains non-ascii characters, then
we assume it is in utf-8 and include the appropriate MIME
headers. If the user has already included a MIME-Version
header, then we assume they know what they are doing and
don't add any headers.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

The git-daemon upload-archive feature has always used the
config directive 'daemon.uploadarch'; the documentation
which came later seems to have just mistakenly used the
wrong name.

Noticed by lionel@over-blog.com.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJon Loeliger <jdl@jdl.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.5.4:
  Documentation/git-describe.txt: make description more readable

Signed-off-by: NIan Hilt <ian.hilt@gmail.com>
Credit-to: Kevin Ballard <kevin@sb.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>