gitweb.git
git-gui: consistently use the same word for "blame... Satoshi Yasushima Tue, 6 Sep 2016 16:02:17 +0000 (01:02 +0900)

git-gui: consistently use the same word for "blame" in Japanese

Signed-off-by: Satoshi Yasushima <s.yasushima@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: consistently use the same word for "remote... Satoshi Yasushima Tue, 6 Sep 2016 16:02:16 +0000 (01:02 +0900)

git-gui: consistently use the same word for "remote" in Japanese

Signed-off-by: Satoshi Yasushima <s.yasushima@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

xdiff: remove unneeded declarationsStefan Beller Sat, 3 Sep 2016 03:16:48 +0000 (20:16 -0700)

xdiff: remove unneeded declarations

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: pt_PT: update Portuguese repository infoVasco Almeida Sat, 3 Sep 2016 12:10:32 +0000 (12:10 +0000)

l10n: pt_PT: update Portuguese repository info

Change Portuguese l10n leadership to Vasco Almeida.

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>

l10n: pt_PT: update Portuguese translationVasco Almeida Sat, 3 Sep 2016 12:02:22 +0000 (12:02 +0000)

l10n: pt_PT: update Portuguese translation

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>

Git 2.10 v2.10.0Junio C Hamano Fri, 2 Sep 2016 16:05:47 +0000 (09:05 -0700)

Git 2.10

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

symbolic-ref -d: do not allow removal of HEADJunio C Hamano Thu, 1 Sep 2016 22:38:02 +0000 (15:38 -0700)

symbolic-ref -d: do not allow removal of HEAD

If you delete the symbolic-ref HEAD from a repository, Git no longer
considers the repository valid, and even "git symbolic-ref HEAD
refs/heads/master" would not be able to recover from that state
(although "git init" can, but that is a sure sign that you are
talking about a "broken" repository).

In the spirit similar to afe5d3d5 ("symbolic ref: refuse non-ref
targets in HEAD", 2009-01-29), forbid removal of HEAD to avoid
corrupting a repository.

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

Merge tag 'l10n-2.10.0-rnd2.2' of git://github.com... Junio C Hamano Fri, 2 Sep 2016 15:48:14 +0000 (08:48 -0700)

Merge tag 'l10n-2.10.0-rnd2.2' of git://github.com/git-l10n/git-po

l10n-2.10.0-rnd2.2

* tag 'l10n-2.10.0-rnd2.2' of git://github.com/git-l10n/git-po:
l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)

Merge branch 'master' of https://github.com/vnwildman/gitJiang Xin Fri, 2 Sep 2016 13:29:48 +0000 (21:29 +0800)

Merge branch 'master' of https://github.com/vnwildman/git

* 'master' of https://github.com/vnwildman/git:
l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)

submodule: avoid auto-discovery in prepare_submodule_re... Junio C Hamano Thu, 1 Sep 2016 20:51:48 +0000 (13:51 -0700)

submodule: avoid auto-discovery in prepare_submodule_repo_env()

The function is used to set up the environment variable used in a
subprocess we spawn in a submodule directory. The callers set up a
child_process structure, find the working tree path of one submodule
and set .dir field to it, and then use start_command() API to spawn
the subprocess like "status", "fetch", etc.

When this happens, we expect that the ".git" (either a directory or
a gitfile that points at the real location) in the current working
directory of the subprocess MUST be the repository for the submodule.

If this ".git" thing is a corrupt repository, however, because
prepare_submodule_repo_env() unsets GIT_DIR and GIT_WORK_TREE, the
subprocess will see ".git", thinks it is not a repository, and
attempt to find one by going up, likely to end up in finding the
repository of the superproject. In some codepaths, this will cause
a command run with the "--recurse-submodules" option to recurse
forever.

By exporting GIT_DIR=.git, disable the auto-discovery logic in the
subprocess, which would instead stop it and report an error.

The test illustrates existing problems in a few callsites of this
function. Without this fix, "git fetch --recurse-submodules", "git
status" and "git diff" keep recursing forever.

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

color_parse_mem: initialize "struct color" temporaryJeff King Wed, 31 Aug 2016 03:43:07 +0000 (23:43 -0400)

color_parse_mem: initialize "struct color" temporary

Compiling color.c with gcc 6.2.0 using -O3 produces some
-Wmaybe-uninitialized false positives:

color.c: In function ‘color_parse_mem’:
color.c:189:10: warning: ‘bg.blue’ may be used uninitialized in this function [-Wmaybe-uninitialized]
out += xsnprintf(out, len, "%c8;2;%d;%d;%d", type,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
c->red, c->green, c->blue);
~~~~~~~~~~~~~~~~~~~~~~~~~~
color.c:208:15: note: ‘bg.blue’ was declared here
struct color bg = { COLOR_UNSPECIFIED };
^~
[ditto for bg.green, bg.red, fg.blue, etc]

This is doubly confusing, because the declaration shows it
being initialized! Even though we do not explicitly
initialize the color components, an incomplete initializer
sets the unmentioned members to zero.

What the warning doesn't show is that we later do this:

struct color c;
if (!parse_color(&c, ...)) {
if (fg.type == COLOR_UNSPECIFIED)
fg = c;
...
}

gcc is clever enough to realize that a struct assignment
from an uninitialized variable taints the destination. But
unfortunately it's _not_ clever enough to realize that we
only look at those members when type is set to COLOR_RGB, in
which case they are always initialized.

With -O2, gcc does not look into parse_color() and must
assume that "c" emerges fully initialized. With -O3, it
inlines parse_color(), and learns just enough to get
confused.

We can silence the false positive by initializing the
temporary "c". This also future-proofs us against
violating the type assumptions (the result would probably
still be buggy, but in a deterministic way).

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

error_errno: use constant return similar to error()Jeff King Wed, 31 Aug 2016 03:41:22 +0000 (23:41 -0400)

error_errno: use constant return similar to error()

Commit e208f9c (make error()'s constant return value more
visible, 2012-12-15) introduced some macro trickery to make
the constant return from error() more visible to callers,
which in turn can help gcc produce better warnings (and
possibly even better code).

Later, fd1d672 (usage.c: add warning_errno() and
error_errno(), 2016-05-08) introduced another variant, and
subsequent commits converted some uses of error() to
error_errno(), losing the magic from e208f9c for those
sites.

As a result, compiling vcs-svn/svndiff.c with "gcc -O3"
produces -Wmaybe-uninitialized false positives (at least
with gcc 6.2.0). Let's give error_errno() the same
treatment, which silences these warnings.

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

A few more fixes before the final 2.10Junio C Hamano Wed, 31 Aug 2016 17:21:05 +0000 (10:21 -0700)

A few more fixes before the final 2.10

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

Merge tag 'l10n-2.10.0-rnd2' of git://github.com/git... Junio C Hamano Wed, 31 Aug 2016 17:04:14 +0000 (10:04 -0700)

Merge tag 'l10n-2.10.0-rnd2' of git://github.com/git-l10n/git-po

l10n-2.10.0-rnd2

* tag 'l10n-2.10.0-rnd2' of git://github.com/git-l10n/git-po:
l10n: zh_CN: for git v2.10.0 l10n round 2
l10n: ca.po: update translation
l10n: fr.po v2.10.0-rc2
l10n: sv.po: Update Swedish translation (2757t0f0u)
l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed)
l10n: Updated Vietnamese translation for v2.10.0 (2789t)
l10n: pt_PT: update Portuguese translation
l10n: pt_PT: merge git.pot
l10n: ko.po: Update Korean translation
l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)

Merge branch 'ls/packet-line-protocol-doc-fix'Junio C Hamano Wed, 31 Aug 2016 17:03:51 +0000 (10:03 -0700)

Merge branch 'ls/packet-line-protocol-doc-fix'

Correct an age-old calco (is that a typo-like word for calc)
in the documentation.

* ls/packet-line-protocol-doc-fix:
pack-protocol: fix maximum pkt-line size

Merge branch 'mh/blame-worktree'Junio C Hamano Wed, 31 Aug 2016 17:03:50 +0000 (10:03 -0700)

Merge branch 'mh/blame-worktree'

* mh/blame-worktree:
blame: fix segfault on untracked files

Merge branch 'kw/patch-ids-optim'Junio C Hamano Wed, 31 Aug 2016 17:03:49 +0000 (10:03 -0700)

Merge branch 'kw/patch-ids-optim'

* kw/patch-ids-optim:
p3400: make test script executable

diff-highlight: avoid highlighting combined diffsJeff King Wed, 31 Aug 2016 05:05:38 +0000 (01:05 -0400)

diff-highlight: avoid highlighting combined diffs

The algorithm in diff-highlight only understands how to look
at two sides of a diff; it cannot correctly handle combined
diffs with multiple preimages. Often highlighting does not
trigger at all for these diffs because the line counts do
not match up. E.g., if we see:

- ours
-theirs
++resolved

we would not bother highlighting; it naively looks like a
single line went away, and then a separate hunk added
another single line.

But of course there are exceptions. E.g., if the other side
deleted the line, we might see:

- ours
++resolved

which looks like we dropped " ours" and added "+resolved".
This is only a small highlighting glitch (we highlight the
space and the "+" along with the content), but it's also the
tip of the iceberg. Even if we learned to find the true
content here (by noticing we are in a 3-way combined diff
and marking _two_ characters from the front of the line as
uninteresting), there are other more complicated cases where
we really do need to handle a 3-way hunk.

Let's just punt for now; we can recognize combined diffs by
the presence of extra "@" symbols in the hunk header, and
treat them as non-diff content.

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

diff-highlight: add multi-byte testsJeff King Wed, 31 Aug 2016 05:03:10 +0000 (01:03 -0400)

diff-highlight: add multi-byte tests

Now that we have a test suite for diff highlight, we can
show off the improvements from 8d00662 (diff-highlight: do
not split multibyte characters, 2015-04-03).

While we're at it, we can also add another case that
_doesn't_ work: combining code points are treated as their
own unit, which means that we may stick colors between them
and the character they are modifying (with the result that
the color is not shown in an xterm, though it's possible
that other terminals err the other way, and show the color
but not the accent). There's no fix here, but let's
document it as a failure.

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

diff-highlight: ignore test cruftJeff King Wed, 31 Aug 2016 05:02:53 +0000 (01:02 -0400)

diff-highlight: ignore test cruft

These are the same as in the normal t/.gitignore, with the
exception of ".prove", as our Makefile does not support it.

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

test-lib: drop PID from test-results/*.countJeff King Tue, 30 Aug 2016 08:43:57 +0000 (04:43 -0400)

test-lib: drop PID from test-results/*.count

Each test run generates a "count" file in t/test-results
that stores the number of successful, failed, etc tests.
If you run "t1234-foo.sh", that file is named as
"t/test-results/t1234-foo-$$.count"

The addition of the PID there is serving no purpose, and
makes analysis of the count files harder.

The presence of the PID dates back to 2d84e9f (Modify
test-lib.sh to output stats to t/test-results/*,
2008-06-08), but no reasoning is given there. Looking at the
current code, we can see that other files we write to
test-results (like *.exit and *.out) do _not_ have the PID
included. So the presence of the PID does not meaningfully
allow one to store the results from multiple runs anyway.

Moreover, anybody wishing to read the *.count files to
aggregate results has to deal with the presence of multiple
files for a given test (and figure out which one is the most
recent based on their timestamps!). The only consumer of
these files is the aggregate.sh script, which arguably gets
this wrong. If a test is run multiple times, its counts will
appear multiple times in the total (I say arguably only
because the desired semantics aren't documented anywhere,
but I have trouble seeing how this behavior could be
useful).

So let's just drop the PID, which fixes aggregate.sh, and
will make new features based around the count files easier
to write.

Note that since the count-file may already exist (when
re-running a test), we also switch the "cat" from appending
to truncating. The use of append here was pointless in the
first place, as we expected to always write to a unique file.

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

pack-protocol: fix maximum pkt-line sizeLars Schneider Mon, 29 Aug 2016 17:55:09 +0000 (19:55 +0200)

pack-protocol: fix maximum pkt-line size

According to LARGE_PACKET_MAX in pkt-line.h the maximal length of a
pkt-line packet is 65520 bytes. The pkt-line header takes 4 bytes and
therefore the pkt-line data component must not exceed 65516 bytes.

Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: zh_CN: for git v2.10.0 l10n round 2Jiang Xin Sun, 28 Aug 2016 02:18:12 +0000 (10:18 +0800)

l10n: zh_CN: for git v2.10.0 l10n round 2

Update 215 translations (2757t0f0u) for git v2.10.0-rc2.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

p3400: make test script executableRené Scharfe Sun, 28 Aug 2016 12:39:27 +0000 (14:39 +0200)

p3400: make test script executable

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-highlight: add support for --graph outputBrian Henderson Mon, 29 Aug 2016 17:33:47 +0000 (10:33 -0700)

diff-highlight: add support for --graph output

Signed-off-by: Brian Henderson <henderson.bj@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-highlight: add failing test for handling --graph... Brian Henderson Mon, 29 Aug 2016 17:33:46 +0000 (10:33 -0700)

diff-highlight: add failing test for handling --graph output

Signed-off-by: Brian Henderson <henderson.bj@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-highlight: add some testsBrian Henderson Mon, 29 Aug 2016 17:33:45 +0000 (10:33 -0700)

diff-highlight: add some tests

Signed-off-by: Brian Henderson <henderson.bj@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

blame: fix segfault on untracked filesThomas Gummerer Sat, 27 Aug 2016 20:01:50 +0000 (21:01 +0100)

blame: fix segfault on untracked files

Since 3b75ee9 ("blame: allow to blame paths freshly added to the index",
2016-07-16) git blame also looks at the index to determine if there is a
file that was freshly added to the index.

cache_name_pos returns -pos - 1 in case there is no match is found, or
if the name matches, but the entry has a stage other than 0. As git
blame should work for unmerged files, it uses strcmp to determine
whether the name of the returned position matches, in which case the
file exists, but is merely unmerged, or if the file actually doesn't
exist in the index.

If the repository is empty, or if the file would lexicographically be
sorted as the last file in the repository, -cache_name_pos - 1 is
outside of the length of the active_cache array, causing git blame to
segfault. Guard against that, and die() normally to restore the old
behaviour.

Reported-by: Simon Ruderich <simon@ruderich.org>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: ca.po: update translationAlex Henrie Sun, 28 Aug 2016 16:32:56 +0000 (10:32 -0600)

l10n: ca.po: update translation

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>

l10n: fr.po v2.10.0-rc2Jean-Noel Avila Sat, 20 Aug 2016 14:20:17 +0000 (16:20 +0200)

l10n: fr.po v2.10.0-rc2

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>

l10n: Updated Vietnamese translation for v2.10.0-rc2... Tran Ngoc Quan Sun, 28 Aug 2016 00:23:30 +0000 (07:23 +0700)

l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

l10n: sv.po: Update Swedish translation (2757t0f0u)Peter Krefting Fri, 26 Aug 2016 13:27:24 +0000 (14:27 +0100)

l10n: sv.po: Update Swedish translation (2757t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

Merge branch 'master' of https://github.com/vnwildman/gitJiang Xin Sat, 27 Aug 2016 15:36:16 +0000 (23:36 +0800)

Merge branch 'master' of https://github.com/vnwildman/git

* 'master' of https://github.com/vnwildman/git:
l10n: Updated Vietnamese translation for v2.10.0 (2789t)

l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed)Jiang Xin Sat, 27 Aug 2016 15:23:26 +0000 (23:23 +0800)

l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed)

Generate po/git.pot from v2.10.0-rc2 for git v2.10.0 l10n round 2.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge branch 'master' of git://github.com/git-l10n... Jiang Xin Sat, 27 Aug 2016 15:14:27 +0000 (23:14 +0800)

Merge branch 'master' of git://github.com/git-l10n/git-po

* 'master' of git://github.com/git-l10n/git-po:
l10n: pt_PT: update Portuguese translation
l10n: pt_PT: merge git.pot
l10n: ko.po: Update Korean translation
l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)

l10n: Updated Vietnamese translation for v2.10.0 (2789t)Tran Ngoc Quan Sat, 27 Aug 2016 02:15:28 +0000 (09:15 +0700)

l10n: Updated Vietnamese translation for v2.10.0 (2789t)

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

SubmittingPatches: use gitk's "Copy commit summary... Beat Bolli Fri, 26 Aug 2016 16:59:01 +0000 (18:59 +0200)

SubmittingPatches: use gitk's "Copy commit summary" format

Update the suggestion in 175d38ca ("SubmittingPatches: document how
to reference previous commits", 2016-07-28) on the format to refer
to a commit to match what gitk has been giving since last year with
its "Copy commit summary" command; also mention this as one of the
ways to obtain a commit reference in this format.

Signed-off-by: Beat Bolli <dev+git@drbeat.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.10-rc2 v2.10.0-rc2Junio C Hamano Fri, 26 Aug 2016 20:59:20 +0000 (13:59 -0700)

Git 2.10-rc2

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

gitattributes: Document the unified "auto" handlingTorsten Bögershausen Fri, 26 Aug 2016 20:18:48 +0000 (22:18 +0200)

gitattributes: Document the unified "auto" handling

Update the documentation about text=auto:
text=auto now follows the core.autocrlf handling when files are not
normalized in the repository.

For a cross platform project recommend the usage of attributes for
line-ending conversions.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Prepare for 2.10.0-rc2Junio C Hamano Thu, 25 Aug 2016 20:56:51 +0000 (13:56 -0700)

Prepare for 2.10.0-rc2

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

Merge branch 'ja/i18n'Junio C Hamano Thu, 25 Aug 2016 20:55:07 +0000 (13:55 -0700)

Merge branch 'ja/i18n'

The recent i18n patch we added during this cycle did a bit too much
refactoring of the messages to avoid word-legos; the repetition has
been reduced to help translators.

* ja/i18n:
i18n: simplify numeric error reporting
i18n: fix git rebase interactive commit messages
i18n: fix typos for translation

Merge branch 'bw/mingw-avoid-inheriting-fd-to-lockfile'Junio C Hamano Thu, 25 Aug 2016 20:55:07 +0000 (13:55 -0700)

Merge branch 'bw/mingw-avoid-inheriting-fd-to-lockfile'

The tempfile (hence its user lockfile) API lets the caller to open
a file descriptor to a temporary file, write into it and then
finalize it by first closing the filehandle and then either
removing or renaming the temporary file. When the process spawns a
subprocess after obtaining the file descriptor, and if the
subprocess has not exited when the attempt to remove or rename is
made, the last step fails on Windows, because the subprocess has
the file descriptor still open. Open tempfile with O_CLOEXEC flag
to avoid this (on Windows, this is mapped to O_NOINHERIT).

* bw/mingw-avoid-inheriting-fd-to-lockfile:
mingw: ensure temporary file handles are not inherited by child processes
t6026-merge-attr: child processes must not inherit index.lock handles

Merge branch 'dg/document-git-c-in-git-config-doc'Junio C Hamano Thu, 25 Aug 2016 20:55:07 +0000 (13:55 -0700)

Merge branch 'dg/document-git-c-in-git-config-doc'

The "git -c var[=val] cmd" facility to append a configuration
variable definition at the end of the search order was described in
git(1) manual page, but not in git-config(1), which was more likely
place for people to look for when they ask "can I make a one-shot
override, and if so how?"

* dg/document-git-c-in-git-config-doc:
doc: mention `git -c` in git-config(1)

Merge branch 'js/no-html-bypass-on-windows'Junio C Hamano Thu, 25 Aug 2016 20:55:06 +0000 (13:55 -0700)

Merge branch 'js/no-html-bypass-on-windows'

On Windows, help.browser configuration variable used to be ignored,
which has been corrected.

* js/no-html-bypass-on-windows:
Revert "display HTML in default browser using Windows' shell API"

Merge branch 'hv/doc-commit-reference-style'Junio C Hamano Thu, 25 Aug 2016 20:55:05 +0000 (13:55 -0700)

Merge branch 'hv/doc-commit-reference-style'

A small doc update.

* hv/doc-commit-reference-style:
SubmittingPatches: document how to reference previous commits

git ls-files: text=auto eol=lf is supported in Git... Torsten Bögershausen Thu, 25 Aug 2016 15:52:57 +0000 (17:52 +0200)

git ls-files: text=auto eol=lf is supported in Git 2.10

The man page for `git ls-files --eol` mentions the combination
of text attributes "text=auto eol=lf" or "text=auto eol=crlf" as not
supported yet, but may be in the future.

Now they are supported.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: pt_PT: update Portuguese translationVasco Almeida Mon, 22 Aug 2016 16:29:35 +0000 (16:29 +0000)

l10n: pt_PT: update Portuguese translation

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>

l10n: pt_PT: merge git.potVasco Almeida Tue, 16 Aug 2016 12:06:44 +0000 (12:06 +0000)

l10n: pt_PT: merge git.pot

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>

i18n: simplify numeric error reportingJean-Noel Avila Sun, 21 Aug 2016 14:50:39 +0000 (16:50 +0200)

i18n: simplify numeric error reporting

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: fix git rebase interactive commit messagesJean-Noel Avila Sun, 21 Aug 2016 14:50:38 +0000 (16:50 +0200)

i18n: fix git rebase interactive commit messages

For proper i18n, the logic cannot embed english specific processing.

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: fix typos for translationJean-Noel Avila Sun, 21 Aug 2016 14:50:37 +0000 (16:50 +0200)

i18n: fix typos for translation

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: mention `git -c` in git-config(1)David Glasser Tue, 23 Aug 2016 17:33:21 +0000 (10:33 -0700)

doc: mention `git -c` in git-config(1)

Signed-off-by: David Glasser <glasser@davidglasser.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: ensure temporary file handles are not inherited... Ben Wijen Mon, 22 Aug 2016 12:47:55 +0000 (14:47 +0200)

mingw: ensure temporary file handles are not inherited by child processes

When the index is locked and child processes inherit the handle to
said lock and the parent process wants to remove the lock before the
child process exits, on Windows there is a problem: it won't work
because files cannot be deleted if a process holds a handle on them.
The symptom:

Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed.
Should I try again? (y/n)

Spawning child processes with bInheritHandles==FALSE would not work
because no file handles would be inherited, not even the hStdXxx
handles in STARTUPINFO (stdin/stdout/stderr).

Opening every file with O_NOINHERIT does not work, either, as e.g.
git-upload-pack expects inherited file handles.

This leaves us with the only way out: creating temp files with the
O_NOINHERIT flag. This flag is Windows-specific, however. For our
purposes, it is equivalent to O_CLOEXEC (which does not exist on
Windows), so let's just open temporary files with the O_CLOEXEC flag and
map that flag to O_NOINHERIT on Windows.

As Eric Wong pointed out, we need to be careful to handle the case where
the Linux headers used to compile Git support O_CLOEXEC but the Linux
kernel used to run Git does not: it returns an EINVAL.

This fixes the test that we just introduced to demonstrate the problem.

Signed-off-by: Ben Wijen <ben@wijen.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: ko.po: Update Korean translationChangwoo Ryu Sun, 21 Aug 2016 13:44:00 +0000 (22:44 +0900)

l10n: ko.po: Update Korean translation

Signed-off-by: Changwoo Ryu <cwryu@debian.org>

Git 2.10-rc1 v2.10.0-rc1Junio C Hamano Fri, 19 Aug 2016 22:39:33 +0000 (15:39 -0700)

Git 2.10-rc1

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

Merge branch 'lt/gpg-show-long-key-in-signature-verific... Junio C Hamano Fri, 19 Aug 2016 22:34:16 +0000 (15:34 -0700)

Merge branch 'lt/gpg-show-long-key-in-signature-verification'

"git log --show-signature" and other commands that display the
verification status of PGP signature now shows the longer key-id,
as 32-bit key-id is so last century.

* lt/gpg-show-long-key-in-signature-verification:
gpg-interface: prefer "long" key format output when verifying pgp signatures

Merge branch 'ab/hooks'Junio C Hamano Fri, 19 Aug 2016 22:34:16 +0000 (15:34 -0700)

Merge branch 'ab/hooks'

"git rev-parse --git-path hooks/<hook>" learned to take
core.hooksPath configuration variable (introduced during 2.9 cycle)
into account.

* ab/hooks:
rev-parse: respect core.hooksPath in --git-path

Merge branch 'jk/difftool-command-not-found'Junio C Hamano Fri, 19 Aug 2016 22:34:15 +0000 (15:34 -0700)

Merge branch 'jk/difftool-command-not-found'

"git difftool" by default ignores the error exit from the backend
commands it spawns, because often they signal that they found
differences by exiting with a non-zero status code just like "diff"
does; the exit status codes 126 and above however are special in
that they are used to signal that the command is not executable,
does not exist, or killed by a signal. "git difftool" has been
taught to notice these exit status codes.

* jk/difftool-command-not-found:
difftool: always honor fatal error exit codes

Merge branch 'sb/checkout-explit-detach-no-advice'Junio C Hamano Fri, 19 Aug 2016 22:34:15 +0000 (15:34 -0700)

Merge branch 'sb/checkout-explit-detach-no-advice'

"git checkout --detach <branch>" used to give the same advice
message as that is issued when "git checkout <tag>" (or anything
that is not a branch name) is given, but asking with "--detach" is
an explicit enough sign that the user knows what is going on. The
advice message has been squelched in this case.

* sb/checkout-explit-detach-no-advice:
checkout: do not mention detach advice for explicit --detach option

Merge branch 'tb/t0027-raciness-fix'Junio C Hamano Fri, 19 Aug 2016 22:34:14 +0000 (15:34 -0700)

Merge branch 'tb/t0027-raciness-fix'

The t0027 test for CRLF conversion was timing dependent and flaky.

* tb/t0027-raciness-fix:
convert: Correct NNO tests and missing `LF will be replaced by CRLF`

Merge branch 'rs/pull-signed-tag'Junio C Hamano Fri, 19 Aug 2016 22:34:13 +0000 (15:34 -0700)

Merge branch 'rs/pull-signed-tag'

When "git merge-recursive" works on history with many criss-cross
merges in "verbose" mode, the names the command assigns to the
virtual merge bases could have overwritten each other by unintended
reuse of the same piece of memory.

* rs/pull-signed-tag:
commit: use FLEX_ARRAY in struct merge_remote_desc
merge-recursive: fix verbose output for multiple base trees
commit: factor out set_merge_remote_desc()
commit: use xstrdup() in get_merge_parent()

Revert "display HTML in default browser using Windows... Johannes Schindelin Fri, 19 Aug 2016 08:39:38 +0000 (10:39 +0200)

Revert "display HTML in default browser using Windows' shell API"

Since 4804aab (help (Windows): Display HTML in default browser using
Windows' shell API, 2008-07-13), Git for Windows used to call
`ShellExecute()` to launch the default Windows handler for `.html`
files.

The idea was to avoid going through a shell script, for performance
reasons.

However, this change ignores the `help.browser` config setting. Together
with browsing help not being a performance-critical operation, let's
just revert that patch.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t6026-merge-attr: child processes must not inherit... Ben Wijen Thu, 18 Aug 2016 14:51:12 +0000 (16:51 +0200)

t6026-merge-attr: child processes must not inherit index.lock handles

On Windows, a file cannot be removed unless all file handles to it have
been released. Hence it is particularly important to close handles when
spawning children (which would probably not even know that they hold on
to those handles).

The example chosen for this test is a custom merge driver that indeed
has no idea that it blocks the deletion of index.lock. The full use case
is a daemon that lives on after the merge, with subsequent invocations
handing off to the daemon, thereby avoiding hefty start-up costs. We
simulate this behavior by simply sleeping one second.

Note that the test only fails on Windows, due to the file locking issue.
Since we have no way to say "expect failure with MINGW, success
otherwise", we simply skip this test on Windows for now.

Signed-off-by: Ben Wijen <ben@wijen.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes: final batch of topics before -rc1Junio C Hamano Wed, 17 Aug 2016 21:09:17 +0000 (14:09 -0700)

RelNotes: final batch of topics before -rc1

Merge branch 'js/test-lint-pathname'Junio C Hamano Wed, 17 Aug 2016 21:07:48 +0000 (14:07 -0700)

Merge branch 'js/test-lint-pathname'

The "t/" hierarchy is prone to get an unusual pathname; "make test"
has been taught to make sure they do not contain paths that cannot
be checked out on Windows (and the mechanism can be reusable to
catch pathnames that are not portable to other platforms as need
arises).

* js/test-lint-pathname:
t/Makefile: ensure that paths are valid on platforms we care

Merge branch 'sg/reflog-past-root'Junio C Hamano Wed, 17 Aug 2016 21:07:48 +0000 (14:07 -0700)

Merge branch 'sg/reflog-past-root'

A small test clean-up for a topic introduced in v2.9.1 and later.

* sg/reflog-past-root:
t1410: remove superfluous 'git reflog' from the 'walk past root' test

Merge branch 'rs/mailinfo-lib'Junio C Hamano Wed, 17 Aug 2016 21:07:47 +0000 (14:07 -0700)

Merge branch 'rs/mailinfo-lib'

Small code clean-up.

* rs/mailinfo-lib:
mailinfo: recycle strbuf in check_header()

Merge branch 'jk/tighten-alloc'Junio C Hamano Wed, 17 Aug 2016 21:07:46 +0000 (14:07 -0700)

Merge branch 'jk/tighten-alloc'

Small code and comment clean-up.

* jk/tighten-alloc:
receive-pack: use FLEX_ALLOC_MEM in queue_command()
correct FLEXPTR_* example in comment

Merge branch 'va/i18n'Junio C Hamano Wed, 17 Aug 2016 21:07:45 +0000 (14:07 -0700)

Merge branch 'va/i18n'

A handful of tests that were broken under gettext-poison build have
been fixed.

* va/i18n:
t7411: become resilient to GETTEXT_POISON
t5520: become resilient to GETTEXT_POISON
t3404: become resilient to GETTEXT_POISON

git-multimail: update to release 1.4.0Matthieu Moy Wed, 17 Aug 2016 06:41:16 +0000 (08:41 +0200)

git-multimail: update to release 1.4.0

Changes are described in CHANGES.

Contributions-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Contributions-by: Irfan Adilovic <irfanadilovic@gmail.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

relnotes: redo the description of text=auto fixJunio C Hamano Wed, 17 Aug 2016 17:18:59 +0000 (10:18 -0700)

relnotes: redo the description of text=auto fix

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

SubmittingPatches: document how to reference previous... Heiko Voigt Thu, 28 Jul 2016 12:55:14 +0000 (14:55 +0200)

SubmittingPatches: document how to reference previous commits

To reference previous commits people used to put just the
abbreviated SHA-1 into commit messages. This is what has evolved as
a more stable format for referencing commits. So lets document it
for everyone to look-up when needed.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'lt/gpg-show-long-key-in-signature-verific... Junio C Hamano Tue, 16 Aug 2016 22:04:13 +0000 (15:04 -0700)

Merge branch 'lt/gpg-show-long-key-in-signature-verification-maint' into lt/gpg-show-long-key-in-signature-verification

Linus's original was rebased to apply to the maintenance track just
in case binary distributors that are stuck in the past want to take
it to their older codebase. Let's merge it up to more modern
codebase that has Peff's gpg-interface clean-up topic that appeared
after Git 2.9 was tagged.

* lt/gpg-show-long-key-in-signature-verification-maint:
gpg-interface: prefer "long" key format output when verifying pgp signatures

gpg-interface: prefer "long" key format output when... Linus Torvalds Tue, 16 Aug 2016 20:10:24 +0000 (13:10 -0700)

gpg-interface: prefer "long" key format output when verifying pgp signatures

Yes, gpg2 already uses the long format by default, but most
distributions seem to still have "gpg" be the older 1.x version due to
compatibility reasons. And older versions of gpg only show the 32-bit
short ID, which is quite insecure.

This doesn't actually matter for the _verification_ itself: if the
verification passes, the pgp signature is good. But if you don't
actually have the key yet, and want to fetch it, or you want to check
exactly which key was used for verification and want to check it, we
should specify the key with more precision.

In fact, we should preferentially specify the whole key fingerprint, but
gpg doesn't actually support that. Which is really quite sad.

Showing the "long" format improves things to at least show 64 bits of
the fingerprint. That's a lot better, even if it's not perfect.

This change the log format for "git log --show-signature" from

commit 2376d31787760af598db23bb3982a57419854e5c
merged tag 'v2.9.3'
gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT using RSA key ID 96AFE6CB
gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
gpg: aka "Junio C Hamano <jch@google.com>"
gpg: aka "Junio C Hamano <junio@pobox.com>"
Merge: 2807cd7b25af e0c1ceafc5be
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Aug 12 10:02:18 2016 -0700

to

commit 2376d31787760af598db23bb3982a57419854e5c
merged tag 'v2.9.3'
gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT
gpg: using RSA key B0B5E88696AFE6CB
gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
gpg: aka "Junio C Hamano <jch@google.com>"
gpg: aka "Junio C Hamano <junio@pobox.com>"
Merge: 2807cd7b25af e0c1ceafc5be
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Aug 12 10:02:18 2016 -0700

(note the longer key ID, but also the reflowing of the text) and also
changes the format in the merge messages when merging a signed
tag.

If you already use gpg2 (either because it's installed by default, or
because you have set your gpg_program configuration to point to gpg2),
that already used the long format, you'll also see a change: it will now
have the same formatting as gpg 1.x, and the verification string looks
something like

gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT
gpg: using RSA key 79BE3E4300411886
gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [ultimate]

where it used to be on one line:

gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT using RSA key ID 79BE3E4300411886
gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [ultimate]

so there is certainly a chance this could break some automated scripting.
But the 32-bit key ID's really are broken. Also note that because of the
differences between gpg-1.x and gpg-2.x, hopefully any scripted key ID
parsing code (if such code exists) is already flexible enough to not care.

This was triggered by the fact that the "evil32" project keys ended up
leaking to the public key servers, so now there are 32-bit aliases for
just about every open source developer that you can easily get by
mistake if you use the 32-bit short ID format.

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

rev-parse: respect core.hooksPath in --git-pathJohannes Schindelin Tue, 16 Aug 2016 13:14:27 +0000 (15:14 +0200)

rev-parse: respect core.hooksPath in --git-path

The idea of the --git-path option is not only to avoid having to
prefix paths with the output of --git-dir all the time, but also to
respect overrides for specific common paths inside the .git directory
(e.g. `git rev-parse --git-path objects` will report the value of the
environment variable GIT_OBJECT_DIRECTORY, if set).

When introducing the core.hooksPath setting, we forgot to adjust
git_path() accordingly. This patch fixes that.

While at it, revert the special-casing of core.hooksPath in
run-command.c, as it is now no longer needed.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/Makefile: ensure that paths are valid on platforms... Johannes Schindelin Tue, 16 Aug 2016 15:13:25 +0000 (17:13 +0200)

t/Makefile: ensure that paths are valid on platforms we care

Some pathnames that are okay on ext4 and on HFS+ cannot be checked
out on Windows. Tests that want to see operations on such paths on
filesystems that support them must do so behind appropriate test
prerequisites, and must not include them in the source tree (instead
they should create them when they run). Otherwise, the source tree
cannot even be checked out.

Make sure that double-quotes, asterisk, colon, greater/less-than,
question-mark, backslash, tab, vertical-bar, as well as any non-ASCII
characters never appear in the pathnames with a new test-lint-* target
as part of a `make test`. To that end, we call `git ls-files` (ensuring
that the paths are quoted properly), relying on the fact that paths
containing non-ASCII characters are quoted within double-quotes.

In case that the source code does not actually live in a Git
repository (e.g. when extracted from a .zip file), or that the `git`
executable cannot be executed, we simply ignore the error for now; In
that case, our trusty Continuous Integration will be the last line of
defense and catch any problematic file name.

Noticed when a topic wanted to add a pathname with '>' in it. A
check like this will prevent a similar problems from happening in the
future.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

difftool: always honor fatal error exit codesJohn Keeping Mon, 15 Aug 2016 21:54:39 +0000 (22:54 +0100)

difftool: always honor fatal error exit codes

At the moment difftool's "trust exit code" logic always suppresses the
exit status of the diff utility we invoke. This is useful because we
don't want to exit just because diff returned "1" because the files
differ, but it's confusing if the shell returns an error because the
selected diff utility is not found.

POSIX specifies 127 as the exit status for "command not found", 126 for
"command found but is not executable" and values greater than 128 if the
command terminated because it received a signal [1] and at least bash
and dash follow this specification, while diff utilities generally use
"1" for the exit status we want to ignore.

Handle any value of 126 or greater as a special value indicating that
some form of fatal error occurred.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout: do not mention detach advice for explicit... Stefan Beller Mon, 15 Aug 2016 18:40:21 +0000 (11:40 -0700)

checkout: do not mention detach advice for explicit --detach option

When a user asked for a detached HEAD specifically with `--detach`,
we do not need to give advice on what a detached HEAD state entails as
we can assume they know what they're getting into as they asked for it.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Relnotes: decribe the updates to the "text=auto" attributeJunio C Hamano Mon, 15 Aug 2016 17:20:38 +0000 (10:20 -0700)

Relnotes: decribe the updates to the "text=auto" attribute

Helped-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1410: remove superfluous 'git reflog' from the 'walk... SZEDER Gábor Sun, 14 Aug 2016 23:28:53 +0000 (01:28 +0200)

t1410: remove superfluous 'git reflog' from the 'walk past root' test

The test added in 71abeb753fa8 (reflog: continue walking the reflog
past root commits, 2016-06-03) contains an unnecessary 'git reflog'
execution, which was part of my debug/tracing instrumentation that I
somehow didn't manage to remove before submitting.

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

l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)Jiang Xin Mon, 15 Aug 2016 14:45:20 +0000 (22:45 +0800)

l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)

Generate po/git.pot from v2.10.0-rc0 for git v2.10.0 l10n round 1.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Git 2.10-rc0 v2.10.0-rc0Junio C Hamano Sun, 14 Aug 2016 21:48:06 +0000 (14:48 -0700)

Git 2.10-rc0

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

convert: Correct NNO tests and missing `LF will be... Torsten Bögershausen Sat, 13 Aug 2016 21:29:27 +0000 (23:29 +0200)

convert: Correct NNO tests and missing `LF will be replaced by CRLF`

When a non-reversible CRLF conversion is done in "git add",
a warning is printed on stderr (or Git dies, depending on checksafe)

The function commit_chk_wrnNNO() in t0027 was written to test this,
but did the wrong thing: Instead of looking at the warning
from "git add", it looked at the warning from "git commit".

This is racy because "git commit" may not have to do CRLF conversion
at all if it can use the sha1 value from the index (which depends on
whether "add" and "commit" run in a single second).

Correct t0027 and replace the commit for each and every file with a commit
of all files in one go.
The function commit_chk_wrnNNO() should be renamed in a separate commit.

Now that t0027 does the right thing, it detects a bug in covert.c:
This sequence should generate the warning `LF will be replaced by CRLF`,
but does not:

$ git init
$ git config core.autocrlf false
$ printf "Line\r\n" >file
$ git add file
$ git commit -m "commit with CRLF"
$ git config core.autocrlf true
$ printf "Line\n" >file
$ git add file

"git add" calls crlf_to_git() in convert.c, which calls check_safe_crlf().
When has_cr_in_index(path) is true, crlf_to_git() returns too early and
check_safe_crlf() is not called at all.

Factor out the code which determines if "git checkout" converts LF->CRLF
into will_convert_lf_to_crlf().

Update the logic around check_safe_crlf() and "simulate" the possible
LF->CRLF conversion at "git checkout" with help of will_convert_lf_to_crlf().
Thanks to Jeff King <peff@peff.net> for analyzing t0027.

Reported-By: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

receive-pack: use FLEX_ALLOC_MEM in queue_command()René Scharfe Sat, 13 Aug 2016 15:38:56 +0000 (17:38 +0200)

receive-pack: use FLEX_ALLOC_MEM in queue_command()

Use the macro FLEX_ALLOC_MEM instead of open-coding it. This shortens
and simplifies the code a bit.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: use FLEX_ARRAY in struct merge_remote_descRené Scharfe Sat, 13 Aug 2016 12:21:27 +0000 (14:21 +0200)

commit: use FLEX_ARRAY in struct merge_remote_desc

Convert the name member of struct merge_remote_desc to a FLEX_ARRAY and
use FLEX_ALLOC_STR to build the struct. This halves the number of
memory allocations, saves the storage for a pointer and avoids an
indirection when reading the name.

Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-recursive: fix verbose output for multiple base... René Scharfe Sat, 13 Aug 2016 12:16:04 +0000 (14:16 +0200)

merge-recursive: fix verbose output for multiple base trees

One of the indirect callers of make_virtual_commit() passes the result of
oid_to_hex() as the name, i.e. a pointer to a static buffer. Since the
function uses that string pointer directly in building a struct
merge_remote_desc, multiple entries can end up sharing the same name
inadvertently.

Fix that by calling set_merge_remote_desc(), which creates a copy of the
string, instead of building the struct by hand.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: factor out set_merge_remote_desc()René Scharfe Sat, 13 Aug 2016 12:11:27 +0000 (14:11 +0200)

commit: factor out set_merge_remote_desc()

Export a helper function for allocating, populating and attaching a
merge_remote_desc to a commit.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: use xstrdup() in get_merge_parent()René Scharfe Sat, 13 Aug 2016 12:09:49 +0000 (14:09 +0200)

commit: use xstrdup() in get_merge_parent()

Handle allocation errors for the name member just like we already do
for the struct merge_remote_desc itself.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mailinfo: recycle strbuf in check_header()René Scharfe Sat, 13 Aug 2016 09:05:42 +0000 (11:05 +0200)

mailinfo: recycle strbuf in check_header()

handle_message_id() duplicates the contents of the strbuf that is passed
to it. Its only caller proceeds to release the strbuf immediately after
that. Reuse it instead and make that change of object ownership more
obvious by inlining this short function.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

correct FLEXPTR_* example in commentRené Scharfe Sat, 13 Aug 2016 09:01:21 +0000 (11:01 +0200)

correct FLEXPTR_* example in comment

This section is about "The FLEXPTR_* variants", so use FLEXPTR_ALLOC_STR
in the example.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: revisions: sort examples and fix alignment of... Philip Oakley Fri, 12 Aug 2016 23:45:22 +0000 (00:45 +0100)

doc: revisions: sort examples and fix alignment of the unchanged

The previous commit adjusted the column alignment for revision
examples which show expansion. Fix the unchanged examples and sort
those that show expansions to the end of the list.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: revisions: show revision expansion in examplesPhilip Oakley Fri, 12 Aug 2016 23:45:21 +0000 (00:45 +0100)

doc: revisions: show revision expansion in examples

The revisions examples show the revison arguments and the selected
commits, but do not show the intermediate step of the expansion of
the special 'range' notations. Extend the examples, including an
all-parents multi-parent merge commit example.

Sort the examples and fix the alignment for those unaffected
in the next commit.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: revisions - clarify reachability examplesPhilip Oakley Fri, 12 Aug 2016 07:07:47 +0000 (08:07 +0100)

doc: revisions - clarify reachability examples

For the r1..r2 case, the exclusion of r1, rather than inclusion of r2,
would be the unexpected case in natural language for a simple linear
development, i.e. start..end excludes start.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: revisions - define `reachable`Philip Oakley Fri, 12 Aug 2016 07:07:46 +0000 (08:07 +0100)

doc: revisions - define `reachable`

Do not self-define `reachable`, which can lead to misunderstanding.
Instead define `reachability` explictly.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: gitrevisions - clarify 'latter case' is revision... Philip Oakley Fri, 12 Aug 2016 07:07:45 +0000 (08:07 +0100)

doc: gitrevisions - clarify 'latter case' is revision walk

The prior sentence has too many clauses for easy parsing.
Replace 'the latter case' with a direct quote.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: gitrevisions - use 'reachable' in page descriptionPhilip Oakley Fri, 12 Aug 2016 07:07:44 +0000 (08:07 +0100)

doc: gitrevisions - use 'reachable' in page description

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: revisions: single vs multi-parent notation comparisonPhilip Oakley Fri, 12 Aug 2016 23:45:20 +0000 (00:45 +0100)

doc: revisions: single vs multi-parent notation comparison

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: revisions: extra clarification of <rev>^! notation... Philip Oakley Fri, 12 Aug 2016 23:45:19 +0000 (00:45 +0100)

doc: revisions: extra clarification of <rev>^! notation effects

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7411: become resilient to GETTEXT_POISONVasco Almeida Fri, 12 Aug 2016 11:59:02 +0000 (11:59 +0000)

t7411: become resilient to GETTEXT_POISON

The concerned test greps the error message in git_parse_source() which
contains "bad config line %d in submodule-blob %s".

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5520: become resilient to GETTEXT_POISONVasco Almeida Fri, 12 Aug 2016 11:59:01 +0000 (11:59 +0000)

t5520: become resilient to GETTEXT_POISON

Use test_i18ngrep function instead of grep for grepping strings.

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>