gitweb.git
test-regex: isolate the bug test codeNguyễn Thái Ngọc Duy Sat, 25 Jun 2016 05:22:28 +0000 (07:22 +0200)

test-regex: isolate the bug test code

This is in preparation to turn test-regex into some generic regex
testing command.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

grep: break down an "if" stmt in preparation for next... Nguyễn Thái Ngọc Duy Sat, 25 Jun 2016 05:22:27 +0000 (07:22 +0200)

grep: break down an "if" stmt in preparation for next changes

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

new-command.txt: correct the command description fileNguyễn Thái Ngọc Duy Sat, 25 Jun 2016 13:55:14 +0000 (15:55 +0200)

new-command.txt: correct the command description file

It has always been command-list.txt even at the time this
new-command.txt document is added.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t2300: "git --exec-path" is not usable in $PATH on... Johannes Schindelin Sat, 18 Jun 2016 10:49:11 +0000 (12:49 +0200)

t2300: "git --exec-path" is not usable in $PATH on Windows as-is

The "git" command prepends the exec-path to the PATH environment
variable for processes it spawns. That is how ". git-sh-setup" in
our scripted Porcelains can find the dot-sourced file in the
exec-path location that is not usually on user's PATH.

When t2300 runs, because it is not spawned by the "git" command, the
scriptlet being tested did not run with a realistic setting of PATH
environment. It lacked the exec-path on the PATH, and failed to
find the dot-sourced file. A recent update to t2300 attempted to
fix this, with "PATH=$(git --exec-path):$PATH", which has been the
recommended way around v1.6.0 days (a script whose original was
written before that release that survives to this day is likely to
have such a line).

However, the "git --exec-path" command outputs C:\path\to\exec\dir
(not /c/path/to/exec/dir) on Windows; the recent update failed to
consider the problem that comes from it.

Even though Git itself, when doing the equivalent internally, does
so in a platform native way (i.e. on Windows, C:\path\to\exec\dir is
prepended to the existing value of %PATH% using ';' as a component
separator), the result is further massaged by bash and gets turned
into $PATH that uses /c/path/to/exec/dir with ':' separating the
components, which is the form understood by bash, so scripted
Porcelains find commands from PATH correctly.

An end user script written in shell, however, cannot prepend
"C:\path\to\exec\dir:" to the existing value of $PATH and expect
bash to magically turn it into the form it understands. In other
words, "PATH=$(git --exec-path):$PATH" does not work as an emulation
of what "Git" internally does to the PATH on Windows.

To correctly emulate how exec-path is prepended to the PATH
environment internally on Windows, we'd need to convert
C:\git-sdk-64\usr\src\git to at least /c\git-sdk-64\usr\src\git
ourselves before prepending it to PATH.

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

commit.c: make find_commit_subject() more robustJohannes Schindelin Wed, 22 Jun 2016 20:20:20 +0000 (22:20 +0200)

commit.c: make find_commit_subject() more robust

Just like the pretty printing machinery, we should simply ignore
blank lines at the beginning of the commit messages.

This discrepancy was noticed when an early version of the
rebase--helper produced commit objects with more than one empty line
between the header and the commit message.

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

pretty: make the skip_blank_lines() function publicJohannes Schindelin Wed, 22 Jun 2016 20:20:16 +0000 (22:20 +0200)

pretty: make the skip_blank_lines() function public

This function will be used also in the find_commit_subject()
function.

While at it, rename the function to reflect that it skips not only
empty lines, but any lines consisting of only whitespace, too.

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

doc: git-htmldocs.googlecode.com is no moreJonathan Nieder Wed, 22 Jun 2016 17:38:25 +0000 (10:38 -0700)

doc: git-htmldocs.googlecode.com is no more

http://git-htmldocs.googlecode.com/git/git.html says

There was no service found for the uri requested.

Link to the rendered documentation on Jekyll instead.

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

git-p4: correct hasBranchPrefix verbose outputAndrew Oakley Wed, 22 Jun 2016 09:26:11 +0000 (10:26 +0100)

git-p4: correct hasBranchPrefix verbose output

The logic here was inverted, you got a message saying the file is
ignored for each file that is not ignored.

Signed-off-by: Andrew Oakley <aoakley@roku.com>
Acked-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7810: fix duplicated test titleCharles Bailey Tue, 21 Jun 2016 21:14:11 +0000 (14:14 -0700)

t7810: fix duplicated test title

Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5614: don't use subshellsStefan Beller Mon, 20 Jun 2016 17:21:18 +0000 (10:21 -0700)

t5614: don't use subshells

Using a subshell for just one git command is both a waste in compute
overhead (create a new process) as well as in line count.

Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7800: readlink may not be availableArmin Kunaschik Tue, 31 May 2016 00:26:12 +0000 (02:26 +0200)

t7800: readlink may not be available

The readlink(1) command is not available on all platforms (notably
not on AIX and HP-UX) and can be replaced in this test with the
"workaround"

ls -ld <name> | sed -e 's/.* -> //'

This is no universal readlink replacement but works in the
controlled test environment well enough.

Signed-off-by: Armin Kunaschik <megabreit@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

perf: accommodate for MacOSXJohannes Schindelin Tue, 21 Jun 2016 13:53:43 +0000 (15:53 +0200)

perf: accommodate for MacOSX

As this developer has no access to MacOSX developer setups anymore,
Travis becomes the best bet to run performance tests on that OS.

However, on MacOSX /usr/bin/time is that good old BSD executable that
no Linux user cares about, as demonstrated by the perf-lib.sh's use
of GNU-ish extensions. And by the hard-coded path.

Let's just work around this issue by using gtime on MacOSX, the
Homebrew-provided GNU implementation onto which pretty much every
MacOSX power user falls back anyway.

To help other developers use Travis to run performance tests on
MacOSX, the .travis.yml file now sports a commented-out line that
installs GNU time via Homebrew.

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

local_tzoffset: detect errors from tm_to_time_tJeff King Mon, 20 Jun 2016 21:14:14 +0000 (17:14 -0400)

local_tzoffset: detect errors from tm_to_time_t

When we want to know the local timezone offset at a given
timestamp, we compute it by asking for localtime() at the
given time, and comparing the offset to GMT at that time.
However, there's some juggling between time_t and "struct
tm" which happens, which involves calling our own
tm_to_time_t().

If that function returns an error (e.g., because it only
handles dates up to the year 2099), it returns "-1", which
we treat as a time_t, and is clearly bogus, leading to
bizarre timestamps (that seem to always adjust the time back
to (time_t)(uint32_t)-1, in the year 2106).

It's not a good idea for local_tzoffset() to simply die
here; it would make it hard to run "git log" on a repository
with funny timestamps. Instead, let's just treat such cases
as "zero offset".

Reported-by: Norbert Kiesel <nkiesel@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0006: test various date formatsJeff King Mon, 20 Jun 2016 21:11:59 +0000 (17:11 -0400)

t0006: test various date formats

We ended up testing some of these date formats throughout
the rest of the suite (e.g., via for-each-ref's
"$(authordate:...)" format), but we never did so
systematically. t0006 is the right place for unit-testing of
our date-handling code.

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

t0006: rename test-date's "show" to "relative"Jeff King Mon, 20 Jun 2016 21:10:29 +0000 (17:10 -0400)

t0006: rename test-date's "show" to "relative"

The "show" tests are really only checking relative formats;
we should make that more clear.

This also frees up the "show" name to later check other
formats. We could later fold "relative" into a more generic
"show" command, but it's not worth it. Relative times are a
special case already because we have to munge the concept of
"now" in our tests.

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

mingw: let the build succeed with DEVELOPER=1Johannes Schindelin Sat, 18 Jun 2016 12:38:36 +0000 (14:38 +0200)

mingw: let the build succeed with DEVELOPER=1

The recently introduced developer flags identified a couple of
old-style function declarations in the Windows-specific code where
the parameter list was left empty instead of specifying "void"
explicitly. Let's just fix them.

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

clone: do not let --depth imply --shallow-submodulesJunio C Hamano Sun, 19 Jun 2016 20:51:56 +0000 (13:51 -0700)

clone: do not let --depth imply --shallow-submodules

In v2.9.0, we prematurely flipped the default to force cloning
submodules shallowly, when the superproject is getting cloned
shallowly. This is likely to fail when the upstream repositories
submodules are cloned from a repository that is not prepared to
serve histories that ends at a commit that is not at the tip of a
branch, and we know the world is not yet ready.

Use a safer default to clone the submodules fully, unless the user
tells us that she knows that the upstream repository of the
submodules are willing to cooperate with "--shallow-submodules"
option.

Noticed-by: Vadim Eisenberg <VADIME@il.ibm.com>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sh-setup: enclose setting of ${VAR=default} in double... LE Manh Cuong Sat, 18 Jun 2016 20:26:03 +0000 (03:26 +0700)

sh-setup: enclose setting of ${VAR=default} in double-quotes

We often make sure an environment variable is set to
something, either set by the user (in which case we do not
molest it) or set it to our default value (otherwise), with

: ${VAR=default value}

i.e. running the no-op command ":" with ${VAR} as its
parameters (or the default value we supply), relying on that
":" is a no-op.

This pattern, even though it is no-op from correctness point
of view, still can be expensive if the existing value in VAR
has shell glob (because they will be expanded against
filesystem entities) and IFS whitespaces (because the value
need to be split into multiple parameters). Our invocation
of ":" command does not care if the parameter given to it is
after the value in VAR goes through these processing.

Enclosing the whole thing in double-quote, i.e.

: "${VAR=default value}"

avoids paying the unnecessary cost, so let's do so.

Signed-off-by: LE Manh Cuong <cuong.manhle.vn@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/technical: signed merge tag formatMichael J Gruber Fri, 17 Jun 2016 07:46:11 +0000 (09:46 +0200)

Documentation/technical: signed merge tag format

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/technical: signed commit formatMichael J Gruber Fri, 17 Jun 2016 07:46:10 +0000 (09:46 +0200)

Documentation/technical: signed commit format

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/technical: signed tag formatMichael J Gruber Fri, 17 Jun 2016 07:46:09 +0000 (09:46 +0200)

Documentation/technical: signed tag format

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/technical: describe signature formatsMichael J Gruber Fri, 17 Jun 2016 07:46:08 +0000 (09:46 +0200)

Documentation/technical: describe signature formats

We use different types of signature formats in different places.
Set up the infrastructure and overview to describe them systematically
in our technical documentation.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase: update comment about FreeBSD /bin/shEd Maste Fri, 17 Jun 2016 15:33:29 +0000 (11:33 -0400)

rebase: update comment about FreeBSD /bin/sh

Commit 9f50d32 introduced a fix for FreeBSD /bin/sh misbehaviour
when dot-sourcing a file containing "return" statements outside of
any function, from a function in another shell script. That issue
affects FreeBSD 9.x, and is not present in the /bin/sh in FreeBSD
10.3 and later. Update the comment to clarify this.

The example from 9f50d32's commit message produces the expected output
on FreeBSD 10.3 and -CURRENT (the upcoming 11.0):

% sh script1.sh
only this line should show
%

Signed-off-by: Ed Maste <emaste@freebsd.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: GPG capitalizationDave Nicolson Thu, 16 Jun 2016 22:15:44 +0000 (22:15 +0000)

Documentation: GPG capitalization

When "GPG" is used in a sentence it is now consistently capitalized.
When referring to the binary it is left as "gpg".

Signed-off-by: David Nicolson <david.nicolson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: always call setup_revisions after init_revisionsJeff King Thu, 16 Jun 2016 23:37:20 +0000 (19:37 -0400)

bisect: always call setup_revisions after init_revisions

init_revisions() initializes the rev_info struct to default
values, and setup_revisions() parses any command-line
arguments and finalizes the struct.

In e22278c (bisect: display first bad commit without forking
a new process, 2009-05-28), a show_diff_tree() was added
that calls the former but not the latter. It doesn't have
any arguments to parse, but it still should do the
finalizing step.

This may have caused other minor bugs over the years, but it
became much more prominent after fe37a9c (pretty: allow
tweaking tabwidth in --expand-tabs, 2016-03-29). That leaves
the expected tab width as "-1", rather than the true default
of "8". When we see a commit with tabs to be expanded, we
end up trying to add (size_t)-1 spaces to a strbuf, which
complains about the integer overflow.

The fix is easy: just call setup_revisions() with no
arguments.

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

pretty.c: support <direction>|(<negative number>) formsNguyễn Thái Ngọc Duy Thu, 16 Jun 2016 13:18:38 +0000 (20:18 +0700)

pretty.c: support <direction>|(<negative number>) forms

%>|(num), %><|(num) and %<|(num), where num is a positive number, sets a
fixed column from the screen's left border. There is no way for us to
specifiy a column relative to the right border, which is useful when you
want to make use of all terminal space (on big screens). Use negative
num for that. Inspired by Go's array syntax (*).

(*) I know Python has this first (or before Go, at least) but the idea
didn't occur to me until I learned Go.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pretty: pass graph width to pretty formatting for use... Josef Kufner Thu, 16 Jun 2016 13:18:37 +0000 (20:18 +0700)

pretty: pass graph width to pretty formatting for use in '%>|(N)'

Pass graph width to pretty formatting, to make N in '%>|(N)'
include columns consumed by graph rendered when --graph option
is in use.

For example, in the output of

git log --all --graph --pretty='format: [%>|(20)%h] %ar%d'

this change will make all commit hashes align at 20th column from
the edge of the terminal, not from the edge of the graph.

Signed-off-by: Josef Kufner <josef@kufner.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add--interactive: respect diff.compactionHeuristicJeff King Thu, 16 Jun 2016 12:27:29 +0000 (08:27 -0400)

add--interactive: respect diff.compactionHeuristic

We use plumbing to generate the diff, so it doesn't
automatically pick up UI config like compactionHeuristic.
Let's forward it on, since interactive adding is porcelain.

Note that we only need to handle the "true" case. There's no
point in passing --no-compaction-heuristic when the variable
is false, since nothing else could have turned it on.

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

git-svn: document the 'git svn propset' commandAlfred Perlstein Wed, 15 Jun 2016 05:19:50 +0000 (22:19 -0700)

git-svn: document the 'git svn propset' command

Add example usage to the git-svn documentation.

Reported-by: Joseph Pecoraro <pecoraro@apple.com>
Signed-off-by: Alfred Perlstein <alfred@freebsd.org>
Reviewed-by: Eric Wong <e@80x24.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

blame, line-log: do not loop around deref_tag()Junio C Hamano Tue, 14 Jun 2016 20:38:14 +0000 (13:38 -0700)

blame, line-log: do not loop around deref_tag()

These callers appear to expect that deref_tag() is to peel one layer
of a tag, but the function does not work that way; it has its own
loop to unwrap tags until an object that is not a tag appears.

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

gnome-keyring: Don't hard-code pkg-config executableHeiko Becker Tue, 14 Jun 2016 11:27:05 +0000 (13:27 +0200)

gnome-keyring: Don't hard-code pkg-config executable

Helpful if your pkg-config executable has a prefix based on the
architecture, for example.

Signed-off-by: Heiko Becker <heirecka@exherbo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/fetch.c: don't free remote->name after fetchKeith McGuigan Tue, 14 Jun 2016 18:28:56 +0000 (14:28 -0400)

builtin/fetch.c: don't free remote->name after fetch

Make fetch's string_list of remote names own all of its string items
(strdup'ing when necessary) so that it can deallocate them safely
when clearing.

Signed-off-by: Keith McGuigan <kmcguigan@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

strbuf: describe the return value of strbuf_read_filePranit Bauva Tue, 14 Jun 2016 06:14:11 +0000 (11:44 +0530)

strbuf: describe the return value of strbuf_read_file

Mentored-by: Lars Schneider <larsxschneider@gmail.com>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: document that pruning happens before fetchingJeff King Mon, 13 Jun 2016 23:58:51 +0000 (19:58 -0400)

fetch: document that pruning happens before fetching

This was changed in 10a6cc8 (fetch --prune: Run prune before
fetching, 2014-01-02), but it seems that nobody in that
discussion realized we were advertising the "after"
explicitly.

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

Git 2.9 v2.9.0Junio C Hamano Mon, 13 Jun 2016 17:42:13 +0000 (10:42 -0700)

Git 2.9

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

Merge tag 'l10n-2.9.0-rc0' of git://github.com/git... Junio C Hamano Mon, 13 Jun 2016 01:00:57 +0000 (18:00 -0700)

Merge tag 'l10n-2.9.0-rc0' of git://github.com/git-l10n/git-po

l10n-2.9.0-rc0

* tag 'l10n-2.9.0-rc0' of git://github.com/git-l10n/git-po:
l10n: ko.po: Update Korean translation
l10n: ru.po: update Russian translation
l10n: de.po: translate 104 new messages
l10n: zh_CN: review for git v2.9.0 l10n round 1
l10n: zh_CN: for git v2.9.0 l10n round 1
l10n: pt_PT: update Portuguese translation
l10n: pt_PT: update according to git-gui glossary
l10n: pt_PT: merge git.pot file
l10n: Updated Bulgarian translation of git (2597t,0f,0u)
l10n: sv.po: Update Swedish translation (2597t0f0u)
l10n: fr.po v2.9.0rnd1
l10n: Updated Vietnamese translation (2597t)
l10n: git.pot: v2.9.0 round 1 (104 new, 37 removed)
l10n: fr.po Fixed grammar mistake

l10n: ko.po: Update Korean translationChangwoo Ryu Sat, 11 Jun 2016 16:25:58 +0000 (01:25 +0900)

l10n: ko.po: Update Korean translation

Merge branch 'russian-l10n' of https://github.com/DJm00... Jiang Xin Sat, 11 Jun 2016 12:21:52 +0000 (20:21 +0800)

Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru

* 'russian-l10n' of https://github.com/DJm00n/git-po-ru:
l10n: ru.po: update Russian translation

l10n: ru.po: update Russian translationDimitriy Ryazantcev Sat, 11 Jun 2016 09:53:43 +0000 (12:53 +0300)

l10n: ru.po: update Russian translation

Signed-off-by: Dimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com>

Hopefully the final last-minute update before 2.9 finalJunio C Hamano Fri, 10 Jun 2016 22:30:19 +0000 (15:30 -0700)

Hopefully the final last-minute update before 2.9 final

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

Merge branch 'jk/diff-compact-heuristic'Junio C Hamano Fri, 10 Jun 2016 22:26:06 +0000 (15:26 -0700)

Merge branch 'jk/diff-compact-heuristic'

It turns out that the earlier effort to update the heuristics may
want to use a bit more time to mature. Turn it off by default.

* jk/diff-compact-heuristic:
diff: disable compaction heuristic for now

Merge branch 'jk/shell-portability'Junio C Hamano Fri, 10 Jun 2016 22:26:04 +0000 (15:26 -0700)

Merge branch 'jk/shell-portability'

test fixes.

* jk/shell-portability:
t5500 & t7403: lose bash-ism "local"
test-lib: add in-shell "env" replacement

Merge branch 'jc/t2300-setup'Junio C Hamano Fri, 10 Jun 2016 22:26:04 +0000 (15:26 -0700)

Merge branch 'jc/t2300-setup'

A test fix.

* jc/t2300-setup:
t2300: run git-sh-setup in an environment that better mimics the real life

config.c: fix misspelt "occurred" in an error messagePeter Colberg Fri, 10 Jun 2016 19:05:26 +0000 (15:05 -0400)

config.c: fix misspelt "occurred" in an error message

Signed-off-by: Peter Colberg <peter@colberg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refs.h: fix misspelt "occurred" in a commentPeter Colberg Fri, 10 Jun 2016 19:05:26 +0000 (15:05 -0400)

refs.h: fix misspelt "occurred" in a comment

Signed-off-by: Peter Colberg <peter@colberg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: disable compaction heuristic for nowJunio C Hamano Fri, 10 Jun 2016 17:58:55 +0000 (10:58 -0700)

diff: disable compaction heuristic for now

http://lkml.kernel.org/g/20160610075043.GA13411@sigill.intra.peff.net
reports that a change to add a new "function" with common ending
with the existing one at the end of the file is shown like this:

def foo
do_foo_stuff()

+ common_ending()
+end
+
+def bar
+ do_bar_stuff()
+
common_ending()
end

when the new heuristic is in use. In reality, the change is to add
the blank line before "def bar" and everything below, which is what
the code without the new heuristic shows.

Disable the heuristics by default, and resurrect the documentation
for the option and the configuration variables, while clearly
marking the feature as still experimental.

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

l10n: de.po: translate 104 new messagesRalf Thielow Fri, 10 Jun 2016 16:00:46 +0000 (18:00 +0200)

l10n: de.po: translate 104 new messages

Translate 104 new messages came from git.pot update in f517e50
(l10n: git.pot: v2.9.0 round 1 (104 new, 37 removed)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>

xdiff: fix merging of appended hunk with -WRené Scharfe Thu, 9 Jun 2016 21:54:48 +0000 (23:54 +0200)

xdiff: fix merging of appended hunk with -W

When -W is given we search the lines between the end of the current
context and the next change for a function line. If there is none then
we merge those two hunks as they must be part of the same function.

If the next change is an appended chunk we abort the search early in
get_func_line(), however, because its line number is out of range. Fix
that by searching from the end of the pre-image in that case instead.

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

Use "working tree" instead of "working directory" for... Lars Vogel Thu, 9 Jun 2016 18:19:30 +0000 (20:19 +0200)

Use "working tree" instead of "working directory" for git status

Working directory can be easily confused with the current directory.
In one of my patches I already updated the usage of working directory
with working tree for the man page but I noticed that git status also
uses this incorrect term.

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

l10n: zh_CN: review for git v2.9.0 l10n round 1Ray Chen Sun, 5 Jun 2016 16:06:17 +0000 (00:06 +0800)

l10n: zh_CN: review for git v2.9.0 l10n round 1

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

doc: change configuration variables formatTom Russello Wed, 8 Jun 2016 17:23:16 +0000 (19:23 +0200)

doc: change configuration variables format

This change configuration variables that where in italic style
to monospace font according to the guideline. It was obtained with

grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \
sed -e 's/::$//' -e 's/\./\\\\./' | \
xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt

Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: more consistency in environment variables formatTom Russello Tue, 7 Jun 2016 22:35:07 +0000 (00:35 +0200)

doc: more consistency in environment variables format

Wrap with backticks (monospaced font) unwrapped or single-quotes wrapped
(italic type) environment variables which are followed by the word
"environment". It was obtained with:

perl -pi -e "s/\'?(\\\$?[0-9A-Z\_]+)\'?(?= environment ?)/\`\1\`/g" *.txt

One of the main purposes is to stick to the CodingGuidelines as possible so
that people writting new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).

Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: change environment variables formatTom Russello Tue, 7 Jun 2016 22:35:06 +0000 (00:35 +0200)

doc: change environment variables format

This change GIT_* variables that where in italic style to monospaced font
according to the guideline. It was obtained with

perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt

One of the main purposes is to stick to the CodingGuidelines as possible so
that people writting new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).

Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: clearer rule about formatting literalsTom Russello Tue, 7 Jun 2016 22:35:05 +0000 (00:35 +0200)

doc: clearer rule about formatting literals

Make the guideline text that we want for our documentation clearer.

Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tree-diff: avoid alloca for large allocationsJeff King Tue, 7 Jun 2016 22:53:00 +0000 (18:53 -0400)

tree-diff: avoid alloca for large allocations

Commit 72441af (tree-diff: rework diff_tree() to generate
diffs for multiparent cases as well, 2014-04-07) introduced
the use of alloca so that the common cases of commits with 1
or 2 parents would not be adversely affected by going
through the multi-parent code.

However, our xalloca is not ideal when the number of parents
grows very large:

1. If the requested size is too large for our stack,
alloca() has no way to tell us, and we simply segfault
while trying to access the memory.

2. It does not use our usual memory_limit_check() logic.

I measured, and alloca is indeed buying us a very small
speedup over xmalloc()/free(). So we'd want to keep
something like it.

This patch simply puts a conditional in place at each
callsite: we use alloca for common known-small numbers of
parents, and otherwise use the heap. We are technically
still vulnerable to (1), but no more so than if we simply
put a few dozen bytes on the stack, which we must do all the
time anyway. And likewise, we technically miss a memory
limit check if it is tiny, but such a limit is pointless.

An alternative to this would be implement something like:

struct tree *tp, tp_fallback[2];
if (nparent <= ARRAY_SIZE(tp_fallback))
tp = tp_fallback;
else
ALLOC_ARRAY(tp, nparent);
...
if (tp != tp_fallback)
free(tp);

That would let us drop our xalloca() portability code
entirely. But in my measurements, this seemed to perform
slightly worse than the xalloca solution.

Note in the example above, and in the patch below, I've used
ALLOC_ARRAY() to replace the manual xmalloc(nr * sizeof(*x)).
Besides being shorter, this has the bonus that one cannot
accidentally overflow a size_t during that computation.

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

add: add --chmod=+x / --chmod=-x optionsEdward Thomson Tue, 31 May 2016 22:08:18 +0000 (17:08 -0500)

add: add --chmod=+x / --chmod=-x options

The executable bit will not be detected (and therefore will not be
set) for paths in a repository with `core.filemode` set to false,
though the users may still wish to add files as executable for
compatibility with other users who _do_ have `core.filemode`
functionality. For example, Windows users adding shell scripts may
wish to add them as executable for compatibility with users on
non-Windows.

Although this can be done with a plumbing command
(`git update-index --add --chmod=+x foo`), teaching the `git-add`
command allows users to set a file executable with a command that
they're already familiar with.

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

regex: fix a SIZE_MAX macro redefinition warningRamsay Jones Tue, 7 Jun 2016 00:35:33 +0000 (01:35 +0100)

regex: fix a SIZE_MAX macro redefinition warning

Since commit 56a1a3ab ("Silence GCC's \"cast of pointer to integer of a
different size\" warning", 26-10-2015), sparse has been issuing a macro
redefinition warning for the SIZE_MAX macro. However, gcc did not issue
any such warning.

After commit 56a1a3ab, in terms of the order of #includes and #defines,
the code looked something like:

$ cat -n junk.c
1 #include <stddef.h>
2
3 #define SIZE_MAX ((size_t) -1)
4
5 #include <stdint.h>
6
7 int main(int argc, char *argv[])
8 {
9 return 0;
10 }
$
$ gcc junk.c
$

However, if you compile that file with -Wsystem-headers, then it will
also issue a warning. Having set -Wsystem-headers in CFLAGS, using the
config.mak file, then (on cygwin):

$ make compat/regex/regex.o
CC compat/regex/regex.o
In file included from /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/include/stdint.h:9:0,
from compat/regex/regcomp.c:21,
from compat/regex/regex.c:77:
/usr/include/stdint.h:362:0: warning: "SIZE_MAX" redefined
#define SIZE_MAX (__SIZE_MAX__)
^
In file included from compat/regex/regex.c:69:0:
compat/regex/regex_internal.h:108:0: note: this is the location of the previous definition
# define SIZE_MAX ((size_t) -1)
^
$

The compilation of the compat/regex code is somewhat unusual in that the
regex.c file directly #includes the other c files (regcomp.c, regexec.c
and regex_internal.c). Commit 56a1a3ab added an #include of <stdint.h>
to the regcomp.c file, which results in the redefinition, since this is
included after the regex_internal.h header. This header file contains a
'fallback' definition for SIZE_MAX, in order to support systems which do
not have the <stdint.h> header (the HAVE_STDINT_H macro is not defined).

In order to suppress the warning, we move the #include of <stdint.h>
from regcomp.c to the start of the compilation unit, close to the top
of regex.c, prior to the #include of the regex_internal.h header.

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

reflog: continue walking the reflog past root commitsSZEDER Gábor Fri, 3 Jun 2016 20:42:35 +0000 (22:42 +0200)

reflog: continue walking the reflog past root commits

If a repository contains more than one root commit, then its HEAD
reflog may contain multiple "creation events", i.e. entries whose
"from" value is the null sha1. Listing such a reflog currently stops
prematurely at the first such entry, even when the reflog still
contains older entries. This can scare users into thinking that their
reflog got truncated after 'git checkout --orphan'.

Continue walking the reflog past such creation events based on the
preceeding reflog entry's "new" value.

The test 'symbolic-ref writes reflog entry' in t1401-symbolic-ref
implicitly relies on the current behavior of the reflog walker to stop
at a root commit and thus to list only the reflog entries that are
relevant for that test. Adjust the test to explicitly specify the
number of relevant reflog entries to be listed.

Reported-by: Patrik Gustafsson <pvn@textalk.se>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.9-rc2 v2.9.0-rc2Junio C Hamano Mon, 6 Jun 2016 21:19:45 +0000 (14:19 -0700)

Git 2.9-rc2

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

Sync with 2.8.4Junio C Hamano Mon, 6 Jun 2016 21:30:49 +0000 (14:30 -0700)

Sync with 2.8.4

* maint:
Git 2.8.4

Git 2.8.4 v2.8.4Junio C Hamano Mon, 6 Jun 2016 21:29:32 +0000 (14:29 -0700)

Git 2.8.4

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

Merge branch 'kb/msys2-tty' into maintJunio C Hamano Mon, 6 Jun 2016 21:27:38 +0000 (14:27 -0700)

Merge branch 'kb/msys2-tty' into maint

The "are we talking with TTY, doing an interactive session?"
detection has been updated to work better for "Git for Windows".

* kb/msys2-tty:
mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*)

Merge branch 'da/difftool' into maintJunio C Hamano Mon, 6 Jun 2016 21:27:37 +0000 (14:27 -0700)

Merge branch 'da/difftool' into maint

"git difftool" learned to handle unmerged paths correctly in
dir-diff mode.

* da/difftool:
difftool: handle unmerged files in dir-diff mode
difftool: initialize variables for readability

Merge branch 'tb/core-eol-fix' into maintJunio C Hamano Mon, 6 Jun 2016 21:27:36 +0000 (14:27 -0700)

Merge branch 'tb/core-eol-fix' into maint

A couple of bugs around core.autocrlf have been fixed.

* tb/core-eol-fix:
convert.c: ident + core.autocrlf didn't work
t0027: test cases for combined attributes
convert: allow core.autocrlf=input and core.eol=crlf
t0027: make commit_chk_wrnNNO() reliable

Merge branch 'ar/diff-args-osx-precompose' into maintJunio C Hamano Mon, 6 Jun 2016 21:27:35 +0000 (14:27 -0700)

Merge branch 'ar/diff-args-osx-precompose' into maint

Many commands normalize command line arguments from NFD to NFC
variant of UTF-8 on OSX, but commands in the "diff" family did
not, causing "git diff $path" to complain that no such path is
known to Git. They have been taught to do the normalization.

* ar/diff-args-osx-precompose:
diff: run arguments through precompose_argv

Merge branch 'sb/submodule-helper-relative-path'Junio C Hamano Mon, 6 Jun 2016 21:18:55 +0000 (14:18 -0700)

Merge branch 'sb/submodule-helper-relative-path'

A bash-ism "local" has been removed from "git submodule" scripted
Porcelain.

* sb/submodule-helper-relative-path:
submodule: remove bashism from shell script

Merge branch 'sb/submodule-helper-list-signal-unmatch... Junio C Hamano Mon, 6 Jun 2016 21:18:55 +0000 (14:18 -0700)

Merge branch 'sb/submodule-helper-list-signal-unmatch-via-exit-status'

The way how "submodule--helper list" signals unmatch error to its
callers has been updated.

* sb/submodule-helper-list-signal-unmatch-via-exit-status:
submodule--helper: offer a consistent API

git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION... Ville Skyttä Mon, 6 Jun 2016 16:29:33 +0000 (19:29 +0300)

git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_sha

When the shell is in "nounset" or "set -u" mode, referencing unset or
null variables results in an error. Protect $ZSH_VERSION and
$BASH_VERSION against that, and initialize $short_sha before use.

Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cherry-pick: allow to pick to unborn branchesMichael J Gruber Mon, 6 Jun 2016 13:23:54 +0000 (15:23 +0200)

cherry-pick: allow to pick to unborn branches

cherry-pick allows to pick single commits to an empty HEAD, but not
multiple commits.

Allow the multiple commit case, too.

Reported-by: Fabrizio Cucci <fabrizio.cucci@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: zh_CN: for git v2.9.0 l10n round 1Jiang Xin Sun, 29 May 2016 12:40:35 +0000 (20:40 +0800)

l10n: zh_CN: for git v2.9.0 l10n round 1

Update 104 new translations (2596t1f0u) for git v2.9.0-rc0.

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

Almost ready for 2.9-rc2Junio C Hamano Fri, 3 Jun 2016 21:38:35 +0000 (14:38 -0700)

Almost ready for 2.9-rc2

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

Merge branch 'rs/apply-name-terminate'Junio C Hamano Fri, 3 Jun 2016 21:38:04 +0000 (14:38 -0700)

Merge branch 'rs/apply-name-terminate'

Code clean-up.

* rs/apply-name-terminate:
apply: remove unused parameters from name_terminate()

Merge branch 'rs/patch-id-use-skip-prefix'Junio C Hamano Fri, 3 Jun 2016 21:38:03 +0000 (14:38 -0700)

Merge branch 'rs/patch-id-use-skip-prefix'

Code clean-up.

* rs/patch-id-use-skip-prefix:
patch-id: use starts_with() and skip_prefix()

Merge branch 'bd/readme.markdown-more'Junio C Hamano Fri, 3 Jun 2016 21:38:02 +0000 (14:38 -0700)

Merge branch 'bd/readme.markdown-more'

The mark-up in the top-level README.md file has been updated to
typeset CLI command names differently from the body text.

* bd/readme.markdown-more:
README.md: format CLI commands with code syntax

Merge branch 'mm/makefile-developer-can-be-in-config... Junio C Hamano Fri, 3 Jun 2016 21:38:02 +0000 (14:38 -0700)

Merge branch 'mm/makefile-developer-can-be-in-config-mak'

"make DEVELOPER=1" worked as expected; setting DEVELOPER=1 in
config.mak didn't.

* mm/makefile-developer-can-be-in-config-mak:
Makefile: add $(DEVELOPER_CFLAGS) variable
Makefile: move 'ifdef DEVELOPER' after config.mak* inclusion

Merge branch 'em/man-bold-literal'Junio C Hamano Fri, 3 Jun 2016 21:38:02 +0000 (14:38 -0700)

Merge branch 'em/man-bold-literal'

The manpage output of our documentation did not render well in
terminal; typeset literals in bold by default to make them stand
out more.

* em/man-bold-literal:
Documentation: bold literals in man

Merge branch 'pa/cherry-pick-doc-typo'Junio C Hamano Fri, 3 Jun 2016 21:38:02 +0000 (14:38 -0700)

Merge branch 'pa/cherry-pick-doc-typo'

"git cherry-pick --help" had three instances of word "behavior",
one of which was spelled "behaviour", which is updated to match the
other two.

* pa/cherry-pick-doc-typo:
git-cherry-pick.txt: correct a small typo

Merge branch 'mr/send-email-doc-gmail-2fa'Junio C Hamano Fri, 3 Jun 2016 21:38:01 +0000 (14:38 -0700)

Merge branch 'mr/send-email-doc-gmail-2fa'

Typofix.

* mr/send-email-doc-gmail-2fa:
Documentation/git-send-email: fix typo in gmail 2FA section

Merge branch 'js/rebase-i-dedup-call-to-rerere'Junio C Hamano Fri, 3 Jun 2016 21:38:01 +0000 (14:38 -0700)

Merge branch 'js/rebase-i-dedup-call-to-rerere'

"git rebase -i", after it fails to auto-resolve the conflict, had
an unnecessary call to "git rerere" from its very early days, which
was spotted recently; the call has been removed.

* js/rebase-i-dedup-call-to-rerere:
rebase -i: remove an unnecessary 'rerere' invocation

Merge branch 'js/perf-rebase-i'Junio C Hamano Fri, 3 Jun 2016 21:38:00 +0000 (14:38 -0700)

Merge branch 'js/perf-rebase-i'

The one in 'master' has a brown-paper-bag bug that breaks the perf
test when used inside a usual Git repository with a working tree.

* js/perf-rebase-i:
perf: make the tests work without a worktree

rev-list: disable bitmaps when "-n" is used with listin... Jeff King Fri, 3 Jun 2016 07:08:05 +0000 (03:08 -0400)

rev-list: disable bitmaps when "-n" is used with listing objects

You can ask rev-list to use bitmaps to speed up an --objects
traversal, which should generally give you your answers much
faster.

Likewise, you can ask rev-list to limit such a traversal
with `-n`, in which case we'll show only a limited set of
commits (and only the tree and commit objects directly
reachable from those commits).

But if you do both together, the results are nonsensical. We
end up limiting any fallback traversal we do to _find_ the
bitmaps, but the actual set of objects we output will be
picked arbitrarily from the union of any bitmaps we do find,
and will involve the objects of many more commits.

It's possible that somebody might want this as a "show me
what you can, but limit the amount of work you do" flag.
But as with the prior commit clamping "--count", the results
are basically non-deterministic; you'll get the values from
some commits between `n` and the total number, and you can't
tell which.

And unlike the `--count` case, we can't easily generate the
"real" value from the bitmap values (you can't just walk
back `-n` commits and subtract out the reachable objects
from the boundary commits; the bitmaps for `X` record its
total reachability, so you don't know which objects are
directly from `X` itself, which from `X^`, and so on).

So let's just fallback to the non-bitmap code path in this
case, so we always give a sane answer.

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

rev-list: "adjust" results of "--count --use-bitmap... Jeff King Fri, 3 Jun 2016 07:07:34 +0000 (03:07 -0400)

rev-list: "adjust" results of "--count --use-bitmap-index -n"

If you ask rev-list for:

git rev-list --count --use-bitmap-index HEAD

we optimize out the actual traversal and just give you the
number of bits set in the commit bitmap. This is faster,
which is good.

But if you ask to limit the size of the traversal, like:

git rev-list --count --use-bitmap-index -n 100 HEAD

we'll still output the full bitmapped number we found. On
the surface, that might even seem OK. You explicitly asked
to use the bitmap index, and it was cheap to compute the
real answer, so we gave it to you.

But there's something much more complicated going on under
the hood. If we don't have a bitmap directly for HEAD, then
we have to actually traverse backwards, looking for a
bitmapped commit. And _that_ traversal is bounded by our
`-n` count.

This is a good thing, because it bounds the work we have to
do, which is probably what the user wanted by asking for
`-n`. But now it makes the output quite confusing. You might
get many values:

- your `-n` value, if we walked back and never found a
bitmap (or fewer if there weren't that many commits)

- the actual full count, if we found a bitmap root for
every path of our traversal with in the `-n` limit

- any number in between! We might have walked back and
found _some_ bitmaps, but then cut off the traversal
early with some commits not accounted for in the result.

So you cannot even see a value higher than your `-n` and say
"OK, bitmaps kicked in, this must be the real full count".
The only sane thing is for git to just clamp the value to a
maximum of the `-n` value, which means we should output the
exact same results whether bitmaps are in use or not.

The test in t5310 demonstrates this by using `-n 1`.
Without this patch we fail in the full-bitmap case (where we
do not have to traverse at all) but _not_ in the
partial-bitmap case (where we have to walk down to find an
actual bitmap). With this patch, both cases just work.

I didn't implement the crazy in-between case, just because
it's complicated to set up, and is really a subset of the
full-count case, which we do cover.

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

Documentation/git-send-email: fix typo in gmail 2FA... SZEDER Gábor Wed, 1 Jun 2016 23:37:41 +0000 (01:37 +0200)

Documentation/git-send-email: fix typo in gmail 2FA section

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

t2300: run git-sh-setup in an environment that better... Junio C Hamano Wed, 1 Jun 2016 20:30:47 +0000 (13:30 -0700)

t2300: run git-sh-setup in an environment that better mimics the real life

When we run scripted Porcelains, "git" potty has set up the $PATH by
prepending $GIT_EXEC_PATH, the path given by "git --exec-path=$there
$cmd", etc. already. Because of this, scripted Porcelains can
dot-source shell script library like git-sh-setup with simple dot
without specifying any path.

t2300 however dot-sources git-sh-setup without adjusting $PATH like
the real "git" potty does. This has not been a problem so far, but
once git-sh-setup wants to rely on the $PATH adjustment, just like
any scripted Porcelains already do, it would become one. It cannot
for example dot-source another shell library without specifying the
full path to it by prefixing $(git --exec-path).

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

t5500 & t7403: lose bash-ism "local"Junio C Hamano Wed, 1 Jun 2016 20:56:08 +0000 (13:56 -0700)

t5500 & t7403: lose bash-ism "local"

In t5500::check_prot_host_port_path(), diagport is not a variable
used elsewhere and the function is not recursively called so this
can simply lose the "local", which may not be supported by shell
(besides, the function liberally clobbers other variables without
making them "local").

t7403::reset_submodule_urls() overrides the "root" variable used
in the test framework for no good reason; its use is not about
temporarily relocating where the test repositories are created.
This assignment can be made not to clobber the variable by moving
them into the subshells it already uses. Its value is always
$TRASH_DIRECTORY, so we could use it instead there, and this
function that is called only once and its two subshells may not be
necessary (instead, the caller can use "git -C $there config" and
set a value that is derived from $TRASH_DIRECTORY), but this is a
minimum fix that is needed to lose "local".

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

submodule: remove bashism from shell scriptStefan Beller Wed, 1 Jun 2016 00:27:59 +0000 (17:27 -0700)

submodule: remove bashism from shell script

Junio pointed out `relative_path` was using bashisms via the
local variables. As the longer term goal is to rewrite most of the
submodule code in C, do it now.

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

submodule--helper: offer a consistent APIStefan Beller Tue, 31 May 2016 23:59:33 +0000 (16:59 -0700)

submodule--helper: offer a consistent API

In 48308681 (2016-02-29, git submodule update: have a dedicated helper
for cloning), the helper communicated errors back only via exit code,
and dance with printing '#unmatched' in case of error was left to
git-submodule.sh as it uses the output of the helper and pipes it into
shell commands. This change makes the helper consistent by never
printing '#unmatched' in the helper but always handling these piping
issues in the actual shell script.

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

Makefile: add $(DEVELOPER_CFLAGS) variableMatthieu Moy Wed, 1 Jun 2016 08:00:08 +0000 (10:00 +0200)

Makefile: add $(DEVELOPER_CFLAGS) variable

This does not change the behavior, but allows the user to tweak
DEVELOPER_CFLAGS on the command-line or in a config.mak* file if
needed.

This also makes the code somewhat cleaner as it follows the pattern

<initialisation of variables>
<include statements>
<actual build logic>

by specifying which flags to activate in the first part, and actually
activating them in the last one.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-lib: add in-shell "env" replacementJeff King Wed, 1 Jun 2016 07:04:26 +0000 (03:04 -0400)

test-lib: add in-shell "env" replacement

The one-shot environment variable syntax:

FOO=BAR some-program

is unportable when some-program is actually a shell
function, like test_must_fail (on some shells FOO remains
set after the function returns, and on others it does not).

We sometimes get around this by using env, like:

test_must_fail env FOO=BAR some-program

But that only works because test_must_fail's arguments are
themselves a command which can be run. You can't run:

env FOO=BAR test_must_fail some-program

because env does not know about our shell functions. So
there is no equivalent for test_commit, for example, and one
must resort to:

(
FOO=BAR
export FOO
test_commit
)

which is a bit verbose. Let's add a version of "env" that
works _inside_ the shell, by creating a subshell, exporting
variables from its argument list, and running the command.

Its use is demonstrated on a currently-unportable case in
t4014.

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

Git 2.9-rc1 v2.9.0-rc1Junio C Hamano Tue, 31 May 2016 21:07:08 +0000 (14:07 -0700)

Git 2.9-rc1

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

Merge branch 'maint'Junio C Hamano Tue, 31 May 2016 21:12:08 +0000 (14:12 -0700)

Merge branch 'maint'

* maint:
More topics for 2.8.4

More topics for 2.8.4Junio C Hamano Tue, 31 May 2016 21:11:38 +0000 (14:11 -0700)

More topics for 2.8.4

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

Merge branch 'sb/submodule-deinit-all' into maintJunio C Hamano Tue, 31 May 2016 21:09:46 +0000 (14:09 -0700)

Merge branch 'sb/submodule-deinit-all' into maint

Correct faulty recommendation to use "git submodule deinit ." when
de-initialising all submodules, which would result in a strange
error message in a pathological corner case.

* sb/submodule-deinit-all:
submodule deinit: require '--all' instead of '.' for all submodules

Merge branch 'bn/http-cookiefile-config' into maintJunio C Hamano Tue, 31 May 2016 21:08:28 +0000 (14:08 -0700)

Merge branch 'bn/http-cookiefile-config' into maint

"http.cookieFile" configuration variable clearly wants a pathname,
but we forgot to treat it as such by e.g. applying tilde expansion.

* bn/http-cookiefile-config:
http: expand http.cookieFile as a path
Documentation: config: improve word ordering for http.cookieFile

Merge branch 'jk/test-send-sh-x-trace-elsewhere' into... Junio C Hamano Tue, 31 May 2016 21:08:27 +0000 (14:08 -0700)

Merge branch 'jk/test-send-sh-x-trace-elsewhere' into maint

Running tests with '-x' option to trace the individual command
executions is a useful way to debug test scripts, but some tests
that capture the standard error stream and check what the command
said can be broken with the trace output mixed in. When running
our tests under "bash", however, we can redirect the trace output
to another file descriptor to keep the standard error of programs
being tested intact.

* jk/test-send-sh-x-trace-elsewhere:
test-lib: set BASH_XTRACEFD automatically

Merge branch 'js/name-rev-use-oldest-ref' into maintJunio C Hamano Tue, 31 May 2016 21:08:26 +0000 (14:08 -0700)

Merge branch 'js/name-rev-use-oldest-ref' into maint

"git describe --contains" often made a hard-to-justify choice of
tag to give name to a given commit, because it tried to come up
with a name with smallest number of hops from a tag, causing an old
commit whose close descendant that is recently tagged were not
described with respect to an old tag but with a newer tag. It did
not help that its computation of "hop" count was further tweaked to
penalize being on a side branch of a merge. The logic has been
updated to favor using the tag with the oldest tagger date, which
is a lot easier to explain to the end users: "We describe a commit
in terms of the (chronologically) oldest tag that contains the
commit."

* js/name-rev-use-oldest-ref:
name-rev: include taggerdate in considering the best name

rebase -i: remove an unnecessary 'rerere' invocationJohannes Sixt Fri, 27 May 2016 16:28:21 +0000 (18:28 +0200)

rebase -i: remove an unnecessary 'rerere' invocation

Interactive rebase uses 'git cherry-pick' and 'git merge' to replay
commits. Both invoke the 'rerere' machinery when they fail due to merge
conflicts. Note that all code paths with these two commands also invoke
the shell function die_with_patch when the commands fail.

Since commit 629716d2 ("rerere: do use multiple variants") the second
operation of the rerere machinery can be observed by a duplicated
message "Recorded preimage for 'file'". This second operation records
the same preimage as the first one and, hence, only wastes cycles.
Remove the 'git rerere' invocation from die_with_patch.

Shell function die_with_patch can be called after the failure of
"git commit", too, which also calls into the rerere machinery, but it
does so only after a successful commit to record the resolution.
Therefore, it is wrong to call 'git rerere' from die_with_patch after
"git commit" fails.

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

perf: make the tests work without a worktreeRené Scharfe Sun, 29 May 2016 16:43:41 +0000 (18:43 +0200)

perf: make the tests work without a worktree

In regular repositories $source_git and $objects_dir contain relative
paths based on $source. Go there to allow cp to resolve them.

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

grep: -W: don't extend context to trailing empty linesRené Scharfe Sat, 28 May 2016 15:06:19 +0000 (17:06 +0200)

grep: -W: don't extend context to trailing empty lines

Empty lines between functions are shown by grep -W, as it considers them
to be part of the function preceding them. They are not interesting in
most languages. The previous patches stopped showing them for diff -W.

Stop showing empty lines trailing a function with grep -W. Grep scans
the lines of a buffer from top to bottom and prints matching lines
immediately. Thus we need to peek ahead in order to determine if an
empty line is part of a function body and worth showing or not.

Remember how far ahead we peeked in order to avoid having to do so
repeatedly when handling multiple consecutive empty lines.

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

t7810: add test for grep -W and trailing empty context... René Scharfe Sat, 28 May 2016 15:05:41 +0000 (17:05 +0200)

t7810: add test for grep -W and trailing empty context lines

Add a test demonstrating that git grep -W prints empty lines following
the function context we're actually interested in. The modified test
file makes it necessary to adjust three unrelated test cases.

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