tokkee.org

Merge branch 'jk/maint-cvsimport-pathname'

* jk/maint-cvsimport-pathname:
  cvsimport: fix relative argument filenames

Merge branch 'iv/tar-lzma-xz'

* iv/tar-lzma-xz:
  import-tars: Add support for tarballs compressed with lzma, xz

Merge branch 'bg/clone-doc'

* bg/clone-doc:
  git-clone.txt: Fix grammar and formatting

Merge branch 'jc/receive-pack-auto'

* jc/receive-pack-auto:
  receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
  gc --auto --quiet: make the notice a bit less verboase

Merge branch 'jc/fsck-default-full'

* jc/fsck-default-full:
  fsck: default to "git fsck --full"

Sync with 1.6.5.2

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

GIT 1.6.5.2

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

Merge branch 'jc/maint-fix-unpack-zlib-check' into maint

* jc/maint-fix-unpack-zlib-check:
  Fix incorrect error check while reading deflated pack data

Merge branch 'maint-1.6.4' into maint

* maint-1.6.4:
  ls-files: excludes should not impact tracked files

Merge branch 'jk/maint-1.6.3-ls-files-no-ignore-cached' into maint-1.6.4

* jk/maint-1.6.3-ls-files-no-ignore-cached:
  ls-files: excludes should not impact tracked files

Merge branch 'jn/maint-1.6.3-check-ref-format-doc' into maint-1.6.4

* jn/maint-1.6.3-check-ref-format-doc:
  Documentation: describe check-ref-format --branch

Merge branch 'maint'

* maint:
  t7800-difftool: fix the effectless GIT_DIFFTOOL_PROMPT test
  Work around option parsing bug in the busybox tar implementation

t7800-difftool: fix the effectless GIT_DIFFTOOL_PROMPT test

GIT_DIFFTOOL_PROMPT doesn't have any effect if overridden with --prompt.

Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Work around option parsing bug in the busybox tar implementation

The first argument of the tar command is interpreted as a bundle of
letters specifying the mode of operation and additional options, with
any option arguments taken from subsequent words on the command line
as needed.  The implementation of tar in busybox treats this bundle
as if preceded by a dash and then parses it by getopt rules, which
mishandles 'tar xfo -'.  Use 'tar xof -' instead to work this around.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  Fix list of released versions in the toc document
  Do not fail "describe --always" in a tag-less repository

Fix list of released versions in the toc document

Merge branch 'jp/maint-send-email-fold' into maint

* jp/maint-send-email-fold:
  git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s

Merge branch 'jn/maint-1.6.3-check-ref-format-doc' into maint

* jn/maint-1.6.3-check-ref-format-doc:
  Documentation: describe check-ref-format --branch

Merge branch 'pv/maint-add-p-no-exclude' into maint

* pv/maint-add-p-no-exclude:
  git-add--interactive: never skip files included in index

Do not fail "describe --always" in a tag-less repository

This fixes a regression introduce by d68dc34 (git-describe: Die early if
there are no possible descriptions, 2009-08-06).

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

Fix incorrect error check while reading deflated pack data

The loop in get_size_from_delta() feeds a deflated delta data from the
pack stream _until_ we get inflated result of 20 bytes[*] or we reach the
end of stream.

    Side note. This magic number 20 does not have anything to do with the
    size of the hash we use, but comes from 1a3b55c (reduce delta head
    inflated size, 2006-10-18).

The loop reads like this:

    do {
        in = use_pack();
        stream.next_in = in;
        st = git_inflate(&stream, Z_FINISH);
        curpos += stream.next_in - in;
    } while ((st == Z_OK || st == Z_BUF_ERROR) &&
             stream.total_out < sizeof(delta_head));

This git_inflate() can return:

 - Z_STREAM_END, if use_pack() fed it enough input and the delta itself
   was smaller than 20 bytes;

 - Z_OK, when some progress has been made;

 - Z_BUF_ERROR, if no progress is possible, because we either ran out of
   input (due to corrupt pack), or we ran out of output before we saw the
   end of the stream.

The fix b3118bd (sha1_file: Fix infinite loop when pack is corrupted,
2009-10-14) attempted was against a corruption that appears to be a valid
stream that produces a result larger than the output buffer, but we are
not even trying to read the stream to the end in this loop.  If avail_out
becomes zero, total_out will be the same as sizeof(delta_head) so the loop
will terminate without the "fix".  There is no fix from b3118bd needed for
this loop, in other words.

The loop in unpack_compressed_entry() is quite a different story.  It
feeds a deflated stream (either delta or base) and allows the stream to
produce output up to what we expect but no more.

    do {
        in = use_pack();
        stream.next_in = in;
        st = git_inflate(&stream, Z_FINISH);
        curpos += stream.next_in - in;
    } while (st == Z_OK || st == Z_BUF_ERROR)

This _does_ risk falling into an endless interation, as we can exhaust
avail_out if the length we expect is smaller than what the stream wants to
produce (due to pack corruption).  In such a case, avail_out will become
zero and inflate() will return Z_BUF_ERROR, while avail_in may (or may
not) be zero.

But this is not a right fix:

    do {
        in = use_pack();
        stream.next_in = in;
        st = git_inflate(&stream, Z_FINISH);
+       if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out)
+               break; /* wants more input??? */
        curpos += stream.next_in - in;
    } while (st == Z_OK || st == Z_BUF_ERROR)

as Z_BUF_ERROR from inflate() may be telling us that avail_in has also run
out before reading the end of stream marker.  In such a case, both avail_in
and avail_out would be zero, and the loop should iterate to allow the end
of stream marker to be seen by inflate from the input stream.

The right fix for this loop is likely to be to increment the initial
avail_out by one (we allocate one extra byte to terminate it with NUL
anyway, so there is no risk to overrun the buffer), and break out if we
see that avail_out has become zero, in order to detect that the stream
wants to produce more than what we expect.  After the loop, we have a
check that exactly tests this condition:

    if ((st != Z_STREAM_END) || stream.total_out != size) {
        free(buffer);
        return NULL;
    }

So here is a patch (without my previous botched attempts) to fix this
issue.  The first hunk reverts the corresponding hunk from b3118bd, and
the second hunk is the same fix proposed earlier.

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

Merge branch 'maint'

* maint:
  Document `delta` attribute in "git help attributes".
  Mark files in t/t5100 as UTF-8
  Remove a left-over file from t/t5100

Merge branch 'gb/maint-gitweb-esc-param'

* gb/maint-gitweb-esc-param:
  gitweb: fix esc_param

git-clone.txt: Fix grammar and formatting

Add the missing definite article ("the") in several places.

Change "note to..." to "note for...", since "note to" means that
that the note is addressed to someone (source: Google search).

Change "progressbar" to "progress bar" (source: Wikipedia).

Format git commands, options, and file names consistently using
back quotes (i.e. a fixed font in the resulting HTML document).

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

import-tars: Add support for tarballs compressed with lzma, xz

Also handle the extensions .tlz and .txz, aliases for .tar.lzma and
.tar.xz respectively.

Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
Liked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

receive-pack: run "gc --auto --quiet" and optionally "update-server-info"

Introduce two new configuration variables, receive.autogc (defaults to
true) and receive.updateserverinfo (defaults to false).  When these are
set, receive-pack runs "gc --auto --quiet" and "update-server-info"
respectively after it finishes receiving data from "git push" and updating
refs.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>

gc --auto --quiet: make the notice a bit less verboase

When "gc --auto --quiet" decides there is something to do, it tells the
user what it is doing, as it is going to make the user wait for a bit.

But the message was a bit too long.

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

Document `delta` attribute in "git help attributes".

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

Mark files in t/t5100 as UTF-8

This enables gitk to show the patch text with correct glyphs if the locale
is not UTF-8.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Remove a left-over file from t/t5100

This mbox file must have been added by accident in e9fe804 (git-mailinfo:
Fix getting the subject from the in-body [PATCH] line, 2008-07-14).

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fsck: default to "git fsck --full"

Linus and other git developers from the early days trained their fingers
to type the command, every once in a while even without thinking, to check
the consistency of the repository back when the lower core part of the git
was still being developed.  Developers who wanted to make sure that git
correctly dealt with packfiles could deliberately trigger their creation
and checked them after they were created carefully, but loose objects are
the ones that are written by various commands from random codepaths.  It
made some technical sense to have a mode that checked only loose objects
from the debugging point of view for that reason.

Even for git developers, there no longer is any reason to type "git fsck"
every five minutes these days, worried that some newly created objects
might be corrupt due to recent change to git.

The reason we did not make "--full" the default is probably we trust our
filesystems a bit too much.  At least, we trusted filesystems more than we
trusted the lower core part of git that was under development.

Once a packfile is created and we always use it read-only, there didn't
seem to be much point in suspecting that the underlying filesystems or
disks may corrupt them in such a way that is not caught by the SHA-1
checksum over the entire packfile and per object checksum.  That trust in
the filesystems might have been a good tradeoff between fsck performance
and reliability on platforms git was initially developed on and for, but
it may not be true anymore as we run on many more platforms these days.

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

Merge branch 'maint'

* maint:
  Documentation/git-gc.txt: change "references" to "reference"

Documentation/git-gc.txt: change "references" to "reference"

Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'bg/rebase-reword'

* bg/rebase-reword:
  rebase -i: fix reword when using a terminal editor
  Teach 'rebase -i' the command "reword"

rebase -i: fix reword when using a terminal editor

We don't want to use output() on git-commit --amend when rewording the
commit message. This leads to confusion as the editor is run in a
subshell with it's output saved away, leaving the user with a seemingly
frozen terminal.

Fix by removing the output part.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format_commit_message(): fix function signature

The format template string was declared as "const void *" for some unknown
reason, even though it obviously is meant to be passed a string.  Make it
"const char *".

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

cvsimport: fix relative argument filenames

One of the first things that cvsimport does is chdir to the
newly created git repo. This means that any filenames given
to us on the command line will be looked up relative to the
git repo directory. This is probably not what the user
expects, so let's remember and prepend the original
directory for relative filenames.

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

Merge branch 'jp/maint-send-email-fold'

* jp/maint-send-email-fold:
  git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s

Merge branch 'cc/replace-no-replace'

* cc/replace-no-replace:
  git: add --no-replace-objects option to disable replacing

Merge branch 'jn/maint-1.6.3-check-ref-format-doc'

* jn/maint-1.6.3-check-ref-format-doc:
  Documentation: describe check-ref-format --branch

Merge branch 'jk/maint-1.6.3-ls-files-no-ignore-cached'

* jk/maint-1.6.3-ls-files-no-ignore-cached:
  ls-files: excludes should not impact tracked files

Merge branch 'jn/gitweb-show-size'

* jn/gitweb-show-size:
  gitweb: Add 'show-sizes' feature to show blob sizes in tree view

Merge branch 'jp/fetch-tag-match'

* jp/fetch-tag-match:
  fetch: Speed up fetch by rewriting find_non_local_tags

Merge branch 'jn/gitweb-patch'

* jn/gitweb-patch:
  gitweb: Do not show 'patch' link for merge commits

Merge branch 'tf/doc-pt-br'

* tf/doc-pt-br:
  Documentation: update pt-BR

Merge branch 'dk/blame-el'

* dk/blame-el:
  git-blame.el: Change how blame information is shown.

Merge branch 'mr/instaweb-cgid'

* mr/instaweb-cgid:
  instaweb: support mod_cgid for apache2

describe: load refnames before calling describe()

Get rid of the static variable that was used to prevent loading all
the refnames multiple times by moving that code out of describe(),
simply making sure it is only run once that way.

Also change the error message that is shown in case no refnames are
found to not include a hash any more, as the error condition is not
specific to any particular revision.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  git push: say that --tag can't be used with --all or --mirror in help text
  git push: remove incomplete options list from help text
  document push's new quiet option
  Makefile: clean block-sha1/ directory instead of mozilla-sha1/

git push: say that --tag can't be used with --all or --mirror in help text

This replaces an earlier patch by Björn Gustavsson,

  Message-ID: <4AD75029.1010109@gmail.com>

Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git push: remove incomplete options list from help text

'git push -h' shows usage text with incomplete list of options and then
has a separate list of options that are supported. Imitate the way other
commands (I looked at 'git diff' for an example) show their options.

Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

document push's new quiet option

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

Makefile: clean block-sha1/ directory instead of mozilla-sha1/

'make clean' should remove the object files from block-sha1/
instead of the non-existent mozilla-sha1/ directory.

Signed-off-by: Carlos R. Mafra <crmafra@aei.mpg.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start 1.6.6 cycle

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

Merge branch 'jc/maint-blank-at-eof'

* jc/maint-blank-at-eof:
  diff -B: colour whitespace errors
  diff.c: emit_add_line() takes only the rest of the line
  diff.c: split emit_line() from the first char and the rest of the line
  diff.c: shuffling code around
  diff --whitespace: fix blank lines at end
  core.whitespace: split trailing-space into blank-at-{eol,eof}
  diff --color: color blank-at-eof
  diff --whitespace=warn/error: fix blank-at-eof check
  diff --whitespace=warn/error: obey blank-at-eof
  diff.c: the builtin_diff() deals with only two-file comparison
  apply --whitespace: warn blank but not necessarily empty lines at EOF
  apply --whitespace=warn/error: diagnose blank at EOF
  apply.c: split check_whitespace() into two
  apply --whitespace=fix: detect new blank lines at eof correctly
  apply --whitespace=fix: fix handling of blank lines at the eof

Merge branch 'maint'

* maint:
  GIT 1.6.5.1
  grep: do not segfault when -f is used

GIT 1.6.5.1

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

Merge branch 'maint-1.6.4' into maint

* maint-1.6.4:
  grep: do not segfault when -f is used

grep: do not segfault when -f is used

"git grep" would segfault if its -f option was used because it would
try to use an uninitialized strbuf, so initialize the strbuf.

Thanks to Johannes Sixt <j.sixt@viscovery.net> for the help with the
test cases.

Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'pv/maint-add-p-no-exclude'

* pv/maint-add-p-no-exclude:
  git-add--interactive: never skip files included in index

Merge branch 'maint'

* maint:
  sha1_file: Fix infinite loop when pack is corrupted

sha1_file: Fix infinite loop when pack is corrupted

Some types of corruption to a pack may confuse the deflate stream
which stores an object.  In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.

Z_BUF_ERROR is returned from inflate() if either the input buffer
needs more input bytes, or the output buffer has run out of space.
Previously we only considered the former case, as it meant we needed
to move the stream's input buffer to the next window in the pack.

We now abort the loop if inflate() returns Z_BUF_ERROR without
consuming the entire input buffer it was given, or has filled
the entire output buffer but has not yet returned Z_STREAM_END.
Either state is a clear indicator that this loop is not working
as expected, and should not continue.

This problem cannot occur with loose objects as we open the entire
loose object as a single buffer and treat Z_BUF_ERROR as an error.

Reported-by: Andy Isaacson <adi@hexapodia.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  change throughput display units with fast links
  clone: Supply the right commit hash to post-checkout when -b is used
  remote-curl: add missing initialization of argv0_path

change throughput display units with fast links

Switch to MiB/s when the connection is fast enough (i.e. on a LAN).

Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

clone: Supply the right commit hash to post-checkout when -b is used

When we use -b <branch>, we may checkout something else than what the
remote's HEAD references, but we still used remote_head to supply the
new ref value to the post-checkout hook, which is wrong.

So instead of using remote_head to find the value to be passed to the
post-checkout hook, we have to use our_head_points_at, which is always
correctly setup, even if -b is not used.

This also fixes a segfault when "clone -b <branch>" is used with a
remote repo that doesn't have a valid HEAD, as in such a case
remote_head is NULL, but we still tried to access it.

Reported-by: Devin Cofer <ranguvar@archlinux.us>
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: fix esc_param

The custom CGI escaping done in esc_param failed to escape UTF-8
properly. Fix by using CGI::escape on each sequence of matched
characters instead of sprintf()ing a custom escaping for each byte.

Additionally, the space -> + escape was being escaped due to greedy
matching on the first substitution. Fix by adding space to the
list of characters not handled on the first substitution.

Finally, remove an unnecessary escaping of the + sign.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote-curl: add missing initialization of argv0_path

All programs, in particular also the stand-alone programs (non-builtins)
must call git_extract_argv0_path(argv[0]) in order to help builds that
derive the installation prefix at runtime, such as the MinGW build.
Without this call, the program segfaults (or raises an assertion
failure).

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Tested-by: Michael Wookey <michaelwookey@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git: add --no-replace-objects option to disable replacing

Commit dae556b (environment: add global variable to disable replacement)
adds a variable to enable/disable replacement, and it is enabled by
default for most commands.

So there is no way to disable it for some commands, which is annoying
when we want to get information about a commit that has been replaced.

For example:

$ git cat-file -p N

would output information about the replacement commit if commit N is
replaced.

With the "--no-replace-objects" option that this patch adds it is
possible to get information about the original commit using:

$ git --no-replace-objects cat-file -p N

While at it, let's add some documentation about this new option in the
"git replace" man page too.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  git-stash documentation: mention default options for 'list'

Merge branch 'maint-1.6.4' into maint

* maint-1.6.4:
  git-stash documentation: mention default options for 'list'

Documentation: describe check-ref-format --branch

Unless one already knew, it was not obvious what sort of shorthand
"git check-ref-format --branch" expands.  Explain it.

The --branch argument is not optional.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Let --decorate show HEAD position

'git log --graph --oneline --decorate --all' is a useful way to get a
general overview of the repository state, similar to 'gitk --all'.
Let it indicate the position of HEAD by loading that ref too, so that
the --decorate code can see it.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-stash documentation: mention default options for 'list'

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

bash completion: complete refs for git-grep

Before the --, always attempt ref completion.  This helps with
entering the <treeish> arguments to git-grep.  As a bonus, you can
work around git-grep's current lack of --all by hitting M-*, ugly as
the resulting command line may be.

Strictly speaking, completing the regular expression argument (or
option argument) makes no sense.  However, we cannot prevent _all_
completion (it will fall back to filenames), so we dispense with any
additional complication to detect whether the user still has to enter
a regular expression.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ls-files: excludes should not impact tracked files

In all parts of git, .gitignore and other exclude files
impact only how we treat untracked files; they should have
no effect on files listed in the index.

This behavior was originally implemented very early on in
9ff768e, but only for --exclude-from. Later, commit 63d285c
accidentally caused us to trigger the behavior for
--exclude-per-directory.

This patch totally ignores excludes for files found in the
index. This means we are reversing the original intent of
9ff768e, while at the same time fixing the accidental
behavior of 63d285c. This is a good thing, though, as the
way that 9ff768e behaved does not really make sense with the
way exclusions are used in modern git.

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

diff.c: stylefix

Essentially; s/type* /type */ as per the coding guidelines.

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

Documentation: add 'git replace' to main git manpage

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-add--interactive: never skip files included in index

Make "git add -p" to not skip files that are in index even if they are
excluded (by .gitignore etc.). This fixes the contradictory behavior
that "git status" and "git commit -a" listed such files as modified, but
"git add -p FILENAME" ignored them.

Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT 1.6.5

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

git-svn: hide find_parent_branch output in double quiet mode

Hide find_parent_branch logging when -qq is specified.
This eliminates more unnecessary output when run from cron, e.g.:

Found possible branch point:
http://undernet-ircu.svn.sourceforge.net/svnroot/undernet-ircu/ircu2/trunk =>
http://undernet-ircu.svn.sourceforge.net/svnroot/undernet-ircu/ircu2/branches/authz,
1919
Found branch parent: (authz) ea061d76aea985dc0208d36fa5e0b2249b698557
Following parent with do_switch
Successfully followed parent

Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: clone: clarify discussion of initial branch

When saying the initial branch is equal to the currently active
remote branch, it is probably intended that the branch heads
point to the same commit.  Maybe it would be more useful to a
new user to emphasize that the tree contents and history are the
same.

More important, probably, is that this new branch is set up so
that "git pull" merges changes from the corresponding remote
branch.  The next paragraph addresses that directly.  What the
reader needs to know to begin with is that (1) the initial branch
is your own; if you do not pull, it won't get updated, and that
(2) the initial branch starts out at the same commit as the
upstream.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s

Some MTAs reject Cc: lines longer than 78 chars.
Avoid this by using the same join as "To:" ",\n\t"
so each subsequent Cc entry is on a new line.

RCPT TO: should have a single entry per line.
see: http://www.ietf.org/rfc/rfc2821.txt

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'rs/maint-archive-prefix'

* rs/maint-archive-prefix:
  Git archive and trailing "/" in prefix

Merge branch 'fc/mutt-alias'

* fc/mutt-alias:
  send-email: fix mutt regex for grouped aliases

Merge branch 'ef/msvc-noreturn'

* ef/msvc-noreturn:
  add NORETURN_PTR for function pointers
  increase portability of NORETURN declarations

Merge branch 'jk/reflog-date'

* jk/reflog-date:
  improve reflog date/number heuristic

Merge branch 'ch/am-header'

* ch/am-header:
  git-am: force egrep to use correct characters set
  git-am: fixed patch_format detection according to RFC2822

bash: add support for 'git replace'

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: fix alias listings with newlines

Aliases with newlines have been a problem since commit 56fc25f (Bash
completion support for remotes in .git/config., 2006-11-05). The chance
of the problem occurring has been slim at best, until commit 518ef8f
(completion: Replace config --list with --get-regexp, 2009-09-11)
removed the case statement introduced by commit 56fc25f. Before removing
the case statement, most aliases with newlines would work unless they
were specially crafted as follows

[alias]
foo = "log -1 --pretty='format:%s\nalias.error=broken'"

After removing the case statement, a more benign alias like

[alias]
whowhat = "log -1 --pretty='format:%an <%ae>\n%s'"
wont-complete = ...

would cause the completion to break badly.

For now, revert the removal of the case statement until someone comes up
with a better way to get keys from git-config.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: fix completion of git <TAB><TAB>

After commit 511a3fc (wrap git's main usage string., 2009-09-12), the
bash completion for git commands includes COMMAND and [ARGS] when it
shouldn't. Fix this by grepping more strictly for a line with git
commands. It's doubtful whether git will ever have commands starting
with anything besides numbers and letters so this should be fine. At
least by being stricter we'll know when we break the completion earlier.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

import-tars: Add missing closing bracket

This fixes an obvious syntax error that snuck in commit 7e787953:

  syntax error at /home/ingmar/bin//git-import-tars line 143, near "/^$/ { "
  syntax error at /home/ingmar/bin//git-import-tars line 145, near "} else"
  syntax error at /home/ingmar/bin//git-import-tars line 152, near "}"

Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
Acked-and-Tested-by: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Do not show 'patch' link for merge commits

The 'patch' view is about generating text/plain patch that can be
given to "git am", and "git am" doesn't understand merges anyway.
Therefore link to 'patch' view should not be shown for merge commits.

Also call to git-format-patch inside the 'patch' action would fail
when 'patch' action is called for a merge commit, with "Reading
git-format-patch failed" text as 'patch' view body.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

racy-git.txt: explain nsec problem in more detail

Idealists may want USE_NSEC to be the default on Linux some day.
Point to a patch to better explain the requirements on
filesystem code for that to happen.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: clarify "working tree" definition

It is not necessarily obvious to a git novice what it means for a
filesystem tree to be equal to the HEAD.  Spell it out.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: clarify branch creation

The documentation seems to assume that the starting point for a new
branch is the tip of an existing (ordinary) branch, but that is not
the most common case.  More often, "git branch" is used to begin
a branch from a remote-tracking branch, a tag, or an interesting
commit (e.g. origin/pu^2).  Clarify the language so it can apply
to these cases.  Thanks to Sean Estabrooks for the wording.

Also add a pointer to the user's manual for the bewildered.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: branch: update --merged description

Update the documentation for --merged and --no-merged to explain
the meaning of the optional parameter introduced in commit 049716b
(branch --merged/--no-merged: allow specifying arbitrary commit,
2008-07-08).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: clarify mergeoptions description

Sounds better this way, at least to my ears.  ("The syntax and
supported options of git merge" is a plural noun.  "the same"
instead of "equal" sounds less technical and seems to convey
the meaning better here.)

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: git fmt-merge-msg does not have to be a script

The fmt-merge-message builtin can be invoked as "git fmt-merge-msg" rather
than through the hard link in GIT_EXEC_PATH.  Although this is unlikely to
confuse most script writers, it should not hurt to make the documentation
a little clearer anyway.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Describe DOCBOOK_XSL_172, ASCIIDOC_NO_ROFF options in Makefile

There is excellent documentation for these options in
Documentation/Makefile, but some users may never find it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pull: improve advice for unconfigured error case

There are several reasons a git-pull invocation might not
have anything marked for merge:

  1. We're not on a branch, so there is no branch
     configuration.

  2. We're on a branch, but there is no configuration for
     this branch.

  3. We fetched from the configured remote, but the
     configured branch to merge didn't get fetched (either
     it doesn't exist, or wasn't part of the fetch refspec).

  4. We fetched from the non-default remote, but didn't
     specify a branch to merge. We can't use the configured
     one because it applies to the default remote.

  5. We fetched from a specified remote, and a refspec was
     given, but it ended up not fetching anything (this is
     actually hard to do; if the refspec points to a remote
     branch and it doesn't exist, then fetch will fail and
     we never make it to this code path. But if you provide
     a wildcard refspec like

       refs/bogus/*:refs/remotes/origin/*

     then you can see this failure).

We have handled (1) and (2) for some time. Recently, commit
a6dbf88 added code to handle case (3).

This patch handles cases (4) and (5), which previously just
fell under other cases, producing a confusing message.

While we're at it, let's rewrap the text for case (3), which
looks terribly ugly as it is.

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