gitweb.git
t1309: document cases where we would want early config... Johannes Schindelin Mon, 13 Mar 2017 20:11:26 +0000 (21:11 +0100)

t1309: document cases where we would want early config not to die()

Jeff King came up with a couple examples that demonstrate how the new
read_early_config() that looks harder for the current .git/ directory
could die() in an undesirable way.

Let's add those cases to the test script, to document what we would like
to happen when early config encounters problems.

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

setup_git_directory_gently_1(): avoid die()ingJohannes Schindelin Mon, 13 Mar 2017 20:11:22 +0000 (21:11 +0100)

setup_git_directory_gently_1(): avoid die()ing

This function now has a new caller in addition to setup_git_directory():
the newly introduced discover_git_directory(). That function wants to
discover the current .git/ directory, and in case of a corrupted one
simply pretend that there is none to be found.

Example: if a stale .git file exists in the parent directory, and the
user calls `git -p init`, we want Git to simply *not* read any
repository config for the pager (instead of aborting with a message that
the .git file is corrupt).

Let's actually pretend that there was no GIT_DIR to be found in that case
when being called from discover_git_directory(), but keep the previous
behavior (i.e. to die()) for the setup_git_directory() case.

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

t1309: test read_early_config()Johannes Schindelin Mon, 13 Mar 2017 20:11:17 +0000 (21:11 +0100)

t1309: test read_early_config()

So far, we had no explicit tests of that function.

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

read_early_config(): really discover .git/Johannes Schindelin Mon, 13 Mar 2017 20:11:12 +0000 (21:11 +0100)

read_early_config(): really discover .git/

Earlier, we punted and simply assumed that we are in the top-level
directory of the project, and that there is no .git file but a .git/
directory so that we can read directly from .git/config.

However, that is not necessarily true. We may be in a subdirectory. Or
.git may be a gitfile. Or the environment variable GIT_DIR may be set.

To remedy this situation, we just refactored the way
setup_git_directory() discovers the .git/ directory, to make it
reusable, and more importantly, to leave all global variables and the
current working directory alone.

Let's discover the .git/ directory correctly in read_early_config() by
using that new function.

This fixes 4 known breakages in t7006.

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

read_early_config(): avoid .git/config hack when unneededJohannes Schindelin Mon, 13 Mar 2017 20:11:08 +0000 (21:11 +0100)

read_early_config(): avoid .git/config hack when unneeded

So far, we only look whether the startup_info claims to have seen a
git_dir.

However, do_git_config_sequence() (and consequently the
git_config_with_options() call used by read_early_config() asks the
have_git_dir() function whether we have a .git/ directory, which in turn
also looks at git_dir and at the environment variable GIT_DIR. And when
this is the case, the repository config is handled already, so we do not
have to do that again explicitly.

Let's just use the same function, have_git_dir(), to determine whether we
have to handle .git/config explicitly.

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

setup: make read_early_config() reusableJohannes Schindelin Mon, 13 Mar 2017 20:11:04 +0000 (21:11 +0100)

setup: make read_early_config() reusable

The pager configuration needs to be read early, possibly before
discovering any .git/ directory.

Let's not hide this function in pager.c, but make it available to other
callers.

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

setup: introduce the discover_git_directory() functionJohannes Schindelin Mon, 13 Mar 2017 20:10:45 +0000 (21:10 +0100)

setup: introduce the discover_git_directory() function

We modified the setup_git_directory_gently_1() function earlier to make
it possible to discover the GIT_DIR without changing global state.

However, it is still a bit cumbersome to use if you only need to figure
out the (possibly absolute) path of the .git/ directory. Let's just
provide a convenient wrapper function with an easier signature that
*just* discovers the .git/ directory.

We will use it in a subsequent patch to fix the early config.

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

setup_git_directory_1(): avoid changing global stateJohannes Schindelin Mon, 13 Mar 2017 20:10:42 +0000 (21:10 +0100)

setup_git_directory_1(): avoid changing global state

For historical reasons, Git searches for the .git/ directory (or the
.git file) by changing the working directory successively to the parent
directory of the current directory, until either anything was found or
until a ceiling or a mount point is hit.

Further global state may be changed in case a .git/ directory was found.

We do have a use case, though, where we would like to find the .git/
directory without having any global state touched, though: when we read
the early config e.g. for the pager or for alias expansion.

Let's just move all of code that changes any global state out of the
function `setup_git_directory_gently_1()` into
`setup_git_directory_gently()`.

In subsequent patches, we will use the _1() function in a new
`discover_git_directory()` function that we will then use for the early
config code.

Note: the new loop is a *little* tricky, as we have to handle the root
directory specially: we cannot simply strip away the last component
including the slash, as the root directory only has that slash. To remedy
that, we introduce the `min_offset` variable that holds the minimal length
of an absolute path, and using that to special-case the root directory,
including an early exit before trying to find the parent of the root
directory.

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

setup: prepare setup_discovered_git_dir() for the root... Johannes Schindelin Mon, 13 Mar 2017 20:09:44 +0000 (21:09 +0100)

setup: prepare setup_discovered_git_dir() for the root directory

Currently, the offset parameter (indicating what part of the cwd
parameter corresponds to the current directory after discovering the
.git/ directory) is set to 0 when we are running in the root directory.

However, in the next patches we will avoid changing the current working
directory while searching for the .git/ directory, meaning that the
offset corresponding to the root directory will have to be 1 to reflect
that this directory is characterized by the path "/" (and not "").

So let's make sure that setup_discovered_git_directory() only tries to
append the trailing slash to non-root directories.

Note: the setup_bare_git_directory() does not need a corresponding
change, as it does not want to return a prefix.

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

add--interactive: do not expand pathspecs with ls-filesJeff King Tue, 14 Mar 2017 16:30:24 +0000 (12:30 -0400)

add--interactive: do not expand pathspecs with ls-files

When we want to get the list of modified files, we first
expand any user-provided pathspecs with "ls-files", and then
feed the resulting list of paths as arguments to
"diff-index" and "diff-files". If your pathspec expands into
a large number of paths, you may run into one of two
problems:

1. The OS may complain about the size of the argument
list, and refuse to run. For example:

$ (ulimit -s 128 && git add -p drivers)
Can't exec "git": Argument list too long at .../git-add--interactive line 177.
Died at .../git-add--interactive line 177.

That's on the linux.git repository, which has about 20K
files in the "drivers" directory (none of them modified
in this case). The "ulimit -s" trick is necessary to
show the problem on Linux even for such a gigantic set
of paths. Other operating systems have much smaller
limits (e.g., a real-world case was seen with only 5K
files on OS X).

2. Even when it does work, it's really slow. The pathspec
code is not optimized for huge numbers of paths. Here's
the same case without the ulimit:

$ time git add -p drivers
No changes.

real 0m16.559s
user 0m53.140s
sys 0m0.220s

We can improve this by skipping "ls-files" completely, and
just feeding the original pathspecs to the diff commands.
This solution was discussed in 2010:

http://public-inbox.org/git/20100105041438.GB12574@coredump.intra.peff.net/

but at the time the diff code's pathspecs were more
primitive than those used by ls-files (e.g., they did not
support globs). Making the change would have caused a
user-visible regression, so we didn't.

Since then, the pathspec code has been unified, and the diff
commands natively understand pathspecs like '*.c'.

This patch implements that solution. That skips the
argument-list limits, and the result runs much faster:

$ time git add -p drivers
No changes.

real 0m0.149s
user 0m0.116s
sys 0m0.080s

There are two new tests. The first just exercises the
globbing behavior to confirm that we are not causing a
regression there. The second checks the actual argument
behavior using GIT_TRACE. We _could_ do it with the "ulimit
-s" trick, as above. But that would mean the test could only
run where "ulimit -s" works. And tests of that sort are
expensive, because we have to come up with enough files to
actually bust the limit (we can't just shrink the "128" down
infinitely, since it is also the in-program stack size).

Finally, two caveats and possibilities for future work:

a. This fixes one argument-list expansion, but there may
be others. In fact, it's very likely that if you run
"git add -i" and select a large number of modified
files that the script would try to feed them all to a
single git command.

In practice this is probably fine. The real issue here
is that the argument list was growing with the _total_
number of files, not the number of modified or selected
files.

b. If the repository contains filenames with literal wildcard
characters (e.g., "foo*"), the original code expanded
them via "ls-files" and then fed those wildcard names
to "diff-index", which would have treated them as
wildcards. This was a bug, which is now fixed (though
unless you really go through some contortions with
":(literal)", it's likely that your original pathspec
would match whatever the accidentally-expanded wildcard
would anyway).

So this takes us one step closer to working correctly
with files whose names contain wildcard characters, but
it's likely that others remain (e.g., if "git add -i"
feeds the selected paths to "git add").

Reported-by: Wincent Colaiuta <win@wincent.com>
Reported-by: Mislav Marohnić <mislav.marohnic@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-status: make porcelain more robustMichael J Gruber Tue, 14 Mar 2017 16:02:02 +0000 (17:02 +0100)

git-status: make porcelain more robust

git status provides a porcelain mode for porcelain writers with a
supposedly stable (plumbing) interface.
7a76c28ff2 ("status: disable translation when --porcelain is used", 2014-03-20)
made sure that ahead/behind info is not translated (i.e. is stable).

Make sure that the remaining two strings (initial commit, detached head)
are stable, too.

These changes are for the v1 porcelain interface. While we do have a perfectly
stable v2 porcelain interface now, some tools (such as
powerline-gitstatus) are written against v1 and profit from fixing v1
without any changes on their side.

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

pathspec: allow escaped query valuesBrandon Williams Mon, 13 Mar 2017 18:23:22 +0000 (11:23 -0700)

pathspec: allow escaped query values

In our own .gitattributes file we have attributes such as:

*.[ch] whitespace=indent,trail,space

When querying for attributes we want to be able to ask for the exact
value, i.e.

git ls-files :(attr:whitespace=indent,trail,space)

should work, but the commas are used in the attr magic to introduce
the next attr, such that this query currently fails with

fatal: Invalid pathspec magic 'trail' in ':(attr:whitespace=indent,trail,space)'

This change allows escaping characters by a backslash, such that the query

git ls-files :(attr:whitespace=indent\,trail\,space)

will match all path that have the value "indent,trail,space" for the
whitespace attribute. To accomplish this, we need to modify two places.
First `parse_long_magic` needs to not stop early upon seeing a comma or
closing paren that is escaped. As a second step we need to remove any
escaping from the attr value.

Based on a patch by Stefan Beller <sbeller@google.com>

Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pathspec: allow querying for attributesBrandon Williams Mon, 13 Mar 2017 18:23:21 +0000 (11:23 -0700)

pathspec: allow querying for attributes

The pathspec mechanism is extended via the new
":(attr:eol=input)pattern/to/match" syntax to filter paths so that it
requires paths to not just match the given pattern but also have the
specified attrs attached for them to be chosen.

Based on a patch by Stefan Beller <sbeller@google.com>
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

path.c: add xdg_cache_homeDevin Lehmacher Mon, 13 Mar 2017 20:43:54 +0000 (16:43 -0400)

path.c: add xdg_cache_home

We already have xdg_config_home to format paths relative to
XDG_CONFIG_HOME. Let's provide a similar function xdg_cache_home to do
the same for paths relative to XDG_CACHE_HOME.

Signed-off-by: Devin Lehmacher <lehmacdj@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http-walker: fix buffer underflow processing remote... Jeff King Mon, 13 Mar 2017 14:04:45 +0000 (10:04 -0400)

http-walker: fix buffer underflow processing remote alternates

If we parse a remote alternates (or http-alternates), we
expect relative lines like:

../../foo.git/objects

which we convert into "$URL/../foo.git/" (and then use that
as a base for fetching more objects).

But if the remote feeds us nonsense like just:

../

we will try to blindly strip the last 7 characters, assuming
they contain the string "objects". Since we don't _have_ 7
characters at all, this results in feeding a small negative
value to strbuf_add(), which converts it to a size_t,
resulting in a big positive value. This should consistently
fail (since we can't generall allocate the max size_t minus
7 bytes), so there shouldn't be any security implications.

Let's fix this by using strbuf_strip_suffix() to drop the
characters we want. If they're not present, we'll ignore the
alternate (in theory we could use it as-is, but the rest of
the http-walker code unconditionally tacks "objects/" back
on, so it is it not prepared to handle such a case).

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

Third batch after 2.12Junio C Hamano Mon, 13 Mar 2017 06:24:14 +0000 (23:24 -0700)

Third batch after 2.12

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

Merge branch 'ah/doc-ls-files-quotepath'Junio C Hamano Mon, 13 Mar 2017 06:21:36 +0000 (23:21 -0700)

Merge branch 'ah/doc-ls-files-quotepath'

Documentation for "git ls-files" did not refer to core.quotePath

* ah/doc-ls-files-quotepath:
Documentation: improve description for core.quotePath

Merge branch 'jc/diff-populate-filespec-size-only-fix'Junio C Hamano Mon, 13 Mar 2017 06:21:36 +0000 (23:21 -0700)

Merge branch 'jc/diff-populate-filespec-size-only-fix'

"git diff --quiet" relies on the size field in diff_filespec to be
correctly populated, but diff_populate_filespec() helper function
made an incorrect short-cut when asked only to populate the size
field for paths that need to go through convert_to_git() (e.g. CRLF
conversion).

* jc/diff-populate-filespec-size-only-fix:
diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec()

Merge branch 'vn/line-log-memcpy-size-fix'Junio C Hamano Mon, 13 Mar 2017 06:21:35 +0000 (23:21 -0700)

Merge branch 'vn/line-log-memcpy-size-fix'

The command-line parsing of "git log -L" copied internal data
structures using incorrect size on ILP32 systems.

* vn/line-log-memcpy-size-fix:
line-log: use COPY_ARRAY to fix mis-sized memcpy

Merge branch 'jk/ewah-use-right-type-in-sizeof'Junio C Hamano Mon, 13 Mar 2017 06:21:35 +0000 (23:21 -0700)

Merge branch 'jk/ewah-use-right-type-in-sizeof'

Code clean-up.

* jk/ewah-use-right-type-in-sizeof:
ewah: fix eword_t/uint64_t confusion

Merge branch 'ax/line-log-range-merge-fix'Junio C Hamano Mon, 13 Mar 2017 06:21:34 +0000 (23:21 -0700)

Merge branch 'ax/line-log-range-merge-fix'

The code to parse "git log -L..." command line was buggy when there
are many ranges specified with -L; overrun of the allocated buffer
has been fixed.

* ax/line-log-range-merge-fix:
line-log.c: prevent crash during union of too many ranges

Merge branch 'ss/remote-bzr-hg-placeholder-wo-python'Junio C Hamano Mon, 13 Mar 2017 06:21:33 +0000 (23:21 -0700)

Merge branch 'ss/remote-bzr-hg-placeholder-wo-python'

There is no need for Python only to give a few messages to the
standard error stream, but we somehow did.

* ss/remote-bzr-hg-placeholder-wo-python:
contrib: git-remote-{bzr,hg} placeholders don't need Python

Merge branch 'js/realpath-pathdup-fix'Junio C Hamano Mon, 13 Mar 2017 06:21:33 +0000 (23:21 -0700)

Merge branch 'js/realpath-pathdup-fix'

Git v2.12 was shipped with an embarrassing breakage where various
operations that verify paths given from the user stopped dying when
seeing an issue, and instead later triggering segfault.

* js/realpath-pathdup-fix:
real_pathdup(): fix callsites that wanted it to die on error
t1501: demonstrate NULL pointer access with invalid GIT_WORK_TREE

Merge branch 'jk/add-i-patch-do-prompt'Junio C Hamano Mon, 13 Mar 2017 06:21:33 +0000 (23:21 -0700)

Merge branch 'jk/add-i-patch-do-prompt'

The patch subcommand of "git add -i" was meant to have paths
selection prompt just like other subcommand, unlike "git add -p"
directly jumps to hunk selection. Recently, this was broken and
"add -i" lost the paths selection dialog, but it now has been
fixed.

* jk/add-i-patch-do-prompt:
add--interactive: fix missing file prompt for patch mode with "-i"

Merge branch 'jh/mingw-openssl-sha1'Junio C Hamano Mon, 13 Mar 2017 06:21:33 +0000 (23:21 -0700)

Merge branch 'jh/mingw-openssl-sha1'

Windows port wants to use OpenSSL's implementation of SHA-1
routines, so let them.

* jh/mingw-openssl-sha1:
mingw: use OpenSSL's SHA-1 routines

blame: move blame_entry duplication to add_blame_entry()René Scharfe Fri, 10 Mar 2017 00:12:59 +0000 (01:12 +0100)

blame: move blame_entry duplication to add_blame_entry()

All callers of add_blame_entry() allocate and copy the second argument.
Let the function do it for them, reducing code duplication.

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

config: add conditional includeNguyễn Thái Ngọc Duy Wed, 1 Mar 2017 11:26:31 +0000 (18:26 +0700)

config: add conditional include

Sometimes a set of repositories want to share configuration settings
among themselves that are distinct from other such sets of repositories.
A user may work on two projects, each of which have multiple
repositories, and use one user.email for one project while using another
for the other.

Setting $GIT_DIR/.config works, but if the penalty of forgetting to
update $GIT_DIR/.config is high (especially when you end up cloning
often), it may not be the best way to go. Having the settings in
~/.gitconfig, which would work for just one set of repositories, would
not well in such a situation. Having separate ${HOME}s may add more
problems than it solves.

Extend the include.path mechanism that lets a config file include
another config file, so that the inclusion can be done only when some
conditions hold. Then ~/.gitconfig can say "include config-project-A
only when working on project-A" for each project A the user works on.

In this patch, the only supported grouping is based on $GIT_DIR (in
absolute path), so you would need to group repositories by directory, or
something like that to take advantage of it.

We already have include.path for unconditional includes. This patch goes
with includeIf.<condition>.path to make it clearer that a condition is
required. The new config has the same backward compatibility approach as
include.path: older git versions that don't understand includeIf will
simply ignore them.

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

config.txt: reflow the second include.path paragraphNguyễn Thái Ngọc Duy Wed, 1 Mar 2017 11:26:30 +0000 (18:26 +0700)

config.txt: reflow the second include.path paragraph

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

config.txt: clarify multiple key values in include... Nguyễn Thái Ngọc Duy Wed, 1 Mar 2017 11:26:29 +0000 (18:26 +0700)

config.txt: clarify multiple key values in include.path

The phrasing in this paragraph may give an impression that you can only
use it once. Rephrase it a bit.

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

t/interop: add test of old clients against modern git... Jeff King Sat, 25 Feb 2017 09:37:30 +0000 (04:37 -0500)

t/interop: add test of old clients against modern git-daemon

This test just checks that old clients can clone and fetch
from a newer git-daemon. The opposite should also be true,
but it's hard to test ancient versions of git-daemon because
they lack basic options like "--listen".

Note that we have to make a slight tweak to the
lib-git-daemon helper from the regular tests, so that it
starts the daemon with our correct git.a version.

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

t: add an interoperability test harnessJeff King Sat, 25 Feb 2017 09:37:07 +0000 (04:37 -0500)

t: add an interoperability test harness

The current test suite is good at letting you test a
particular version of Git. But it's not very good at letting
you test _two_ versions and seeing how they interact (e.g.,
one cloning from the other).

This commit adds a test harness that will build two
arbitrary versions of git and make it easy to call them from
inside your tests. See the README and the example script for
details.

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

Second batch after 2.12Junio C Hamano Fri, 10 Mar 2017 21:24:59 +0000 (13:24 -0800)

Second batch after 2.12

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

Merge branch 'rs/log-email-subject'Junio C Hamano Fri, 10 Mar 2017 21:24:24 +0000 (13:24 -0800)

Merge branch 'rs/log-email-subject'

Code clean-up.

* rs/log-email-subject:
pretty: use fmt_output_email_subject()
log-tree: factor out fmt_output_email_subject()

Merge branch 'tg/stash-push'Junio C Hamano Fri, 10 Mar 2017 21:24:24 +0000 (13:24 -0800)

Merge branch 'tg/stash-push'

"git stash save" takes a pathspec so that the local changes can be
stashed away only partially.

* tg/stash-push:
stash: allow pathspecs in the no verb form
stash: use stash_push for no verb form
stash: teach 'push' (and 'create_stash') to honor pathspec
stash: refactor stash_create
stash: add test for the create command line arguments
stash: introduce push verb

Merge branch 'sb/submodule-init-url-selection'Junio C Hamano Fri, 10 Mar 2017 21:24:24 +0000 (13:24 -0800)

Merge branch 'sb/submodule-init-url-selection'

When "git submodule init" decides that the submodule in the working
tree is its upstream, it now gives a warning as it is not a very
common setup.

* sb/submodule-init-url-selection:
submodule init: warn about falling back to a local path

Merge branch 'rj/remove-unused-mktemp'Junio C Hamano Fri, 10 Mar 2017 21:24:24 +0000 (13:24 -0800)

Merge branch 'rj/remove-unused-mktemp'

Code cleanup.

* rj/remove-unused-mktemp:
wrapper.c: remove unused gitmkstemps() function
wrapper.c: remove unused git_mkstemp() function

Merge branch 'ew/markdown-url-in-readme'Junio C Hamano Fri, 10 Mar 2017 21:24:24 +0000 (13:24 -0800)

Merge branch 'ew/markdown-url-in-readme'

Doc update.

* ew/markdown-url-in-readme:
README: create HTTP/HTTPS links from URLs in Markdown

Merge branch 'ps/docs-diffcore'Junio C Hamano Fri, 10 Mar 2017 21:24:23 +0000 (13:24 -0800)

Merge branch 'ps/docs-diffcore'

Doc update.

* ps/docs-diffcore:
docs/diffcore: unquote "Complete Rewrites" in headers
docs/diffcore: fix grammar in diffcore-rename header

Merge branch 'jt/http-base-url-update-upon-redirect'Junio C Hamano Fri, 10 Mar 2017 21:24:23 +0000 (13:24 -0800)

Merge branch 'jt/http-base-url-update-upon-redirect'

When a redirected http transport gets an error during the
redirected request, we ignored the error we got from the server,
and ended up giving a not-so-useful error message.

* jt/http-base-url-update-upon-redirect:
http: attempt updating base URL only if no error

Merge branch 'jk/http-auth'Junio C Hamano Fri, 10 Mar 2017 21:24:23 +0000 (13:24 -0800)

Merge branch 'jk/http-auth'

Reduce authentication round-trip over HTTP when the server supports
just a single authentication method.

* jk/http-auth:
http: add an "auto" mode for http.emptyauth
http: restrict auth methods to what the server advertises

Merge branch 'jh/send-email-one-cc'Junio C Hamano Fri, 10 Mar 2017 21:24:23 +0000 (13:24 -0800)

Merge branch 'jh/send-email-one-cc'

"Cc:" on the trailer part does not have to conform to RFC strictly,
unlike in the e-mail header. "git send-email" has been updated to
ignore anything after '>' when picking addresses, to allow non-address
cruft like " # stable 4.4" after the address.

* jh/send-email-one-cc:
send-email: only allow one address per body tag

Merge branch 'rs/strbuf-add-real-path'Junio C Hamano Fri, 10 Mar 2017 21:24:23 +0000 (13:24 -0800)

Merge branch 'rs/strbuf-add-real-path'

An helper function to make it easier to append the result from
real_path() to a strbuf has been added.

* rs/strbuf-add-real-path:
strbuf: add strbuf_add_real_path()
cocci: use ALLOC_ARRAY

Merge branch 'rs/sha1-file-plug-fallback-base-leak'Junio C Hamano Fri, 10 Mar 2017 21:24:22 +0000 (13:24 -0800)

Merge branch 'rs/sha1-file-plug-fallback-base-leak'

A leak in a codepath to read from a packed object in (rare) cases
has been plugged.

* rs/sha1-file-plug-fallback-base-leak:
sha1_file: release fallback base's memory in unpack_entry()

Merge branch 'rs/commit-parsing-optim'Junio C Hamano Fri, 10 Mar 2017 21:24:22 +0000 (13:24 -0800)

Merge branch 'rs/commit-parsing-optim'

The code that parses header fields in the commit object has been
updated for (micro)performance and code hygiene.

* rs/commit-parsing-optim:
commit: don't check for space twice when looking for header
commit: be more precise when searching for headers

Merge branch 'jk/t6300-cleanup'Junio C Hamano Fri, 10 Mar 2017 21:24:22 +0000 (13:24 -0800)

Merge branch 'jk/t6300-cleanup'

A test that creates a confusing branch whose name is HEAD has been
corrected not to do so.

* jk/t6300-cleanup:
t6300: avoid creating refs/heads/HEAD

Merge branch 'jk/parse-config-key-cleanup'Junio C Hamano Fri, 10 Mar 2017 21:24:22 +0000 (13:24 -0800)

Merge branch 'jk/parse-config-key-cleanup'

The "parse_config_key()" API function has been cleaned up.

* jk/parse-config-key-cleanup:
parse_hide_refs_config: tell parse_config_key we don't want a subsection
parse_config_key: allow matching single-level config
parse_config_key: use skip_prefix instead of starts_with

Merge branch 'sb/parse-hide-refs-config-cleanup'Junio C Hamano Fri, 10 Mar 2017 21:24:21 +0000 (13:24 -0800)

Merge branch 'sb/parse-hide-refs-config-cleanup'

Code clean-up.

* sb/parse-hide-refs-config-cleanup:
refs: parse_hide_refs_config to use parse_config_key

Merge branch 'jt/upload-pack-error-report'Junio C Hamano Fri, 10 Mar 2017 21:24:21 +0000 (13:24 -0800)

Merge branch 'jt/upload-pack-error-report'

"git upload-pack", which is a counter-part of "git fetch", did not
report a request for a ref that was not advertised as invalid.
This is generally not a problem (because "git fetch" will stop
before making such a request), but is the right thing to do.

* jt/upload-pack-error-report:
upload-pack: report "not our ref" to client

Merge branch 'jk/ident-empty'Junio C Hamano Fri, 10 Mar 2017 21:24:21 +0000 (13:24 -0800)

Merge branch 'jk/ident-empty'

user.email that consists of only cruft chars should consistently
error out, but didn't.

* jk/ident-empty:
ident: do not ignore empty config name/email
ident: reject all-crud ident name
ident: handle NULL email when complaining of empty name
ident: mark error messages for translation

Merge branch 'jc/config-case-cmdline-take-2'Junio C Hamano Fri, 10 Mar 2017 21:24:20 +0000 (13:24 -0800)

Merge branch 'jc/config-case-cmdline-take-2'

The code to parse "git -c VAR=VAL cmd" and set configuration
variable for the duration of cmd had two small bugs, which have
been fixed.

* jc/config-case-cmdline-take-2:
config: use git_config_parse_key() in git_config_parse_parameter()
config: move a few helper functions up

ref-filter: use separate cache for contains_tag_algoJeff King Thu, 9 Mar 2017 13:29:49 +0000 (08:29 -0500)

ref-filter: use separate cache for contains_tag_algo

The algorithm which powers "tag --contains" uses the
TMP_MARK and UNINTERESTING bits, but never cleans up after
itself. As a result, stale UNINTERESTING bits may impact
later traversals (like "--merged").

We could fix this by clearing the bits after we're done with
the --contains traversal. That would be enough to fix the
existing problem, but it leaves future developers in a bad
spot: they cannot add other traversals that operate
simultaneously with --contains (e.g., if you wanted to add
"--no-contains" and use both filters at the same time).

Instead, we can use a commit slab to store our cached
results, which will store the bits outside of the commit
structs entirely. This adds an extra level of indirection,
but in my tests (running "git tag --contains HEAD" on
linux.git), there was no measurable slowdown.

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

ref-filter: die on parse_commit errorsJeff King Thu, 9 Mar 2017 13:29:04 +0000 (08:29 -0500)

ref-filter: die on parse_commit errors

The tag-contains algorithm quietly returns "does not
contain" when parse_commit() fails. But a parse failure is
an indication that the repository is corrupt. We should die
loudly rather than producing a bogus result.

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

ref-filter: use contains_result enum consistentlyJeff King Thu, 9 Mar 2017 13:28:48 +0000 (08:28 -0500)

ref-filter: use contains_result enum consistently

Commit cbc60b672 (git tag --contains: avoid stack overflow,
2014-04-24) adapted the -1/0/1 contains status into a
tri-state enum. However, some of the code still used the
numeric values, or assumed that no/yes correspond to C's
boolean true/false.

Let's switch to using the symbolic values everywhere, which
will make it easier to change them.

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

ref-filter: move ref_cbdata definition into ref-filter.cJeff King Thu, 9 Mar 2017 13:27:55 +0000 (08:27 -0500)

ref-filter: move ref_cbdata definition into ref-filter.c

This is an implementation detail of how filter_refs() works,
and does not need to be exposed to the outside world. This
will become more important in future patches as we add new
private data types to it.

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

branch: honor --abbrev/--no-abbrev in --list modeJunio C Hamano Wed, 8 Mar 2017 22:13:09 +0000 (14:13 -0800)

branch: honor --abbrev/--no-abbrev in --list mode

When the "branch --list" command was converted to use the --format
facility from the ref-filter API, we forgot to honor the --abbrev
setting in the default output format and instead used a hardcoded
"7".

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

rev-parse: add --show-superproject-working-treeStefan Beller Wed, 8 Mar 2017 23:07:42 +0000 (15:07 -0800)

rev-parse: add --show-superproject-working-tree

In some situations it is useful to know if the given repository
is a submodule of another repository.

Add the flag --show-superproject-working-tree to git-rev-parse
to make it easy to find out if there is a superproject. When no
superproject exists, the output will be empty.

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

real_pathdup(): fix callsites that wanted it to die... Johannes Schindelin Wed, 8 Mar 2017 15:43:40 +0000 (16:43 +0100)

real_pathdup(): fix callsites that wanted it to die on error

In 4ac9006f832 (real_path: have callers use real_pathdup and
strbuf_realpath, 2016-12-12), we changed the xstrdup(real_path())
pattern to use real_pathdup() directly.

The problem with this change is that real_path() calls
strbuf_realpath() with die_on_error = 1 while real_pathdup() calls
it with die_on_error = 0. Meaning that in cases where real_path()
causes Git to die() with an error message, real_pathdup() is silent
and returns NULL instead.

The callers, however, are ill-prepared for that change, as they expect
the return value to be non-NULL (and otherwise the function died
with an appropriate error message).

Fix this by extending real_pathdup()'s signature to accept the
die_on_error flag and simply pass it through to strbuf_realpath(),
and then adjust all callers after a careful audit whether they would
handle NULLs well.

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

t1501: demonstrate NULL pointer access with invalid... Johannes Schindelin Wed, 8 Mar 2017 15:43:34 +0000 (16:43 +0100)

t1501: demonstrate NULL pointer access with invalid GIT_WORK_TREE

When GIT_WORK_TREE does not specify a valid path, we should error
out, instead of crashing.

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

setup_git_directory(): use is_dir_sep() helperJohannes Schindelin Tue, 7 Mar 2017 14:32:32 +0000 (15:32 +0100)

setup_git_directory(): use is_dir_sep() helper

It is okay in practice to test for forward slashes in the output of
getcwd(), because we go out of our way to convert backslashes to forward
slashes in getcwd()'s output on Windows.

Still, the correct way to test for a dir separator is by using the
helper function we introduced for that very purpose. It also serves as a
good documentation what the code tries to do (not "how").

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

send-pack: report signal death of pack-objectsJeff King Tue, 7 Mar 2017 13:39:48 +0000 (08:39 -0500)

send-pack: report signal death of pack-objects

If our pack-objects sub-process dies of a signal, then it
likely didn't have a chance to write anything useful to
stderr. The user may be left scratching their head why the
push failed. Let's detect this situation and write something
to stderr.

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

send-pack: read "unpack" status even on pack-objects... Jeff King Tue, 7 Mar 2017 13:38:51 +0000 (08:38 -0500)

send-pack: read "unpack" status even on pack-objects failure

If the local pack-objects of a push fails, we'll tell the
user about it. But one likely cause is that the remote
index-pack stopped reading for some reason (because it
didn't like our input, or encountered another error). In
that case we'd expect the remote to report more details to
us via the "unpack ..." status line. However, the current
code just hangs up completely, and the user never sees it.

Instead, let's call receive_unpack_status(), which will
complain on stderr with whatever reason the remote told us.
Note that if our pack-objects fails because the connection
was severed or the remote just crashed entirely, then our
packet_read_line() call may fail with "the remote end hung
up unexpectedly". That's OK. It's a more accurate
description than what we get now (which is just "some refs
failed to push").

This should be safe from any deadlocks. At the point we make
this call we'll have closed the writing end of the
connection to the server (either by handing it off to
a pack-objects which exited, explicitly in the stateless_rpc
case, or by doing a half-duplex shutdown for a socket). So
there should be no chance that the other side is waiting
for the rest of our pack-objects input.

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

send-pack: improve unpack-status error messagesJeff King Tue, 7 Mar 2017 13:37:36 +0000 (08:37 -0500)

send-pack: improve unpack-status error messages

When the remote tells us that the "unpack" step failed, we
show an error message. However, unless you are familiar with
the internals of send-pack and receive-pack, it was not
clear that this represented an error on the remote side.
Let's re-word to make that more obvious.

Likewise, when we got an unexpected packet from the other
end, we complained with a vague message but did not actually
show the packet. Let's fix that.

And finally, neither message was marked for translation. The
message from the remote probably won't be translated, but
there's no reason we can't do better for the local half.

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

send-pack: use skip_prefix for parsing unpack statusJeff King Tue, 7 Mar 2017 13:36:19 +0000 (08:36 -0500)

send-pack: use skip_prefix for parsing unpack status

This avoids repeating ourselves, and the use of magic
numbers.

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

send-pack: extract parsing of "unpack" responseJeff King Tue, 7 Mar 2017 13:35:57 +0000 (08:35 -0500)

send-pack: extract parsing of "unpack" response

After sending the pack, we call receive_status() which gets
both the "unpack" line and the ref status. Let's break these
into two functions so we can call the first part
independently.

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

receive-pack: fix deadlock when we cannot create tmpdirJeff King Tue, 7 Mar 2017 13:35:34 +0000 (08:35 -0500)

receive-pack: fix deadlock when we cannot create tmpdir

The err_fd descriptor passed to the unpack() function is
intended to be handed off to the child index-pack, and our
async muxer will read until it gets EOF. However, if we
encounter an error before handing off the descriptor, we
must manually close(err_fd). Otherwise we will be waiting
for our muxer to finish, while the muxer is waiting for EOF
on err_fd.

We fixed an identical deadlock already in 49ecfa13f
(receive-pack: close sideband fd on early pack errors,
2013-04-19). But since then, the function grew a new
early-return in 722ff7f87 (receive-pack: quarantine objects
until pre-receive accepts, 2016-10-03), when we fail to
create a temporary directory. This return needs the same
treatment.

Reported-by: Horst Schirmeier <horst@schirmeier.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git svn: fix authentication with 'branch'Hiroshi Shirosaki Mon, 6 Mar 2017 05:59:07 +0000 (14:59 +0900)

git svn: fix authentication with 'branch'

Authentication fails with svn branch while svn rebase and
svn dcommit work fine without authentication failures.

$ git svn branch v7_3
Copying https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx at r27519
to https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/v7_3...
Can't create session: Unable to connect to a repository at URL
'https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx': No more
credentials or we tried too many times.
Authentication failed at
C:\Program Files\Git\mingw64/libexec/git-core\git-svn line 1200.

We add auth configuration to SVN::Client->new() to fix the issue.

Signed-off-by: Hiroshi Shirosaki <h.shirosaki@gmail.com>
Signed-off-by: Eric Wong <e@80x24.org>

Documentation/git-update-index: explain splitIndex.*Christian Couder Mon, 6 Mar 2017 09:42:03 +0000 (10:42 +0100)

Documentation/git-update-index: explain splitIndex.*

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

Documentation/config: add splitIndex.sharedIndexExpireChristian Couder Mon, 6 Mar 2017 09:42:02 +0000 (10:42 +0100)

Documentation/config: add splitIndex.sharedIndexExpire

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

read-cache: use freshen_shared_index() in read_index_from()Christian Couder Mon, 6 Mar 2017 09:42:01 +0000 (10:42 +0100)

read-cache: use freshen_shared_index() in read_index_from()

This way a share index file will not be garbage collected if
we still read from an index it is based from.

As we need to read the current index before creating a new
one, the tests have to be adjusted, so that we don't expect
an old shared index file to be deleted right away when we
create a new one.

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

read-cache: refactor read_index_from()Christian Couder Mon, 6 Mar 2017 09:42:00 +0000 (10:42 +0100)

read-cache: refactor read_index_from()

It looks better and is simpler to review when we don't compute
the same things many times in the function.

It will also help make the following commit simpler.

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

t1700: test shared index file expirationChristian Couder Mon, 6 Mar 2017 09:41:59 +0000 (10:41 +0100)

t1700: test shared index file expiration

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

read-cache: unlink old sharedindex filesChristian Couder Mon, 6 Mar 2017 09:41:58 +0000 (10:41 +0100)

read-cache: unlink old sharedindex files

Everytime split index is turned on, it creates a "sharedindex.XXXX"
file in the git directory. This change makes sure that shared index
files that haven't been used for a long time are removed when a new
shared index file is created.

The new "splitIndex.sharedIndexExpire" config variable is created
to tell the delay after which an unused shared index file can be
deleted. It defaults to "2.weeks.ago".

A previous commit made sure that each time a split index file is
created the mtime of the shared index file it references is updated.
This makes sure that recently used shared index file will not be
deleted.

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

ewah: fix eword_t/uint64_t confusionJeff King Sun, 5 Mar 2017 11:46:38 +0000 (06:46 -0500)

ewah: fix eword_t/uint64_t confusion

The ewah subsystem typedefs eword_t to be uint64_t, but some
code uses a bare uint64_t. This isn't a bug now, but it's a
potential maintenance problem if the definition of eword_t
ever changes. Let's use the correct type.

Note that we can't use COPY_ARRAY() here because the source
and destination point to objects of different sizes. For
that reason we'll also skip the usual "sizeof(*dst)" and use
the real type, which should make it more clear that there's
something tricky going on.

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

line-log: use COPY_ARRAY to fix mis-sized memcpyVegard Nossum Sun, 5 Mar 2017 11:44:46 +0000 (06:44 -0500)

line-log: use COPY_ARRAY to fix mis-sized memcpy

This memcpy meant to get the sizeof a "struct range", not a
"range_set", as the former is what our array holds. Rather
than swap out the types, let's convert this site to
COPY_ARRAY, which avoids the problem entirely (and confirms
that the src and dst types match).

Note for curiosity's sake that this bug doesn't trigger on
I32LP64 systems, but does on ILP32 systems. The mistaken
"struct range_set" has two ints and a pointer. That's 16
bytes on LP64, or 12 on ILP32. The correct "struct range"
type has two longs, which is also 16 on LP64, but only 8 on
ILP32.

Likewise an IL32P64 system would experience the bug.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Travis: also test on 32-bit LinuxJohannes Schindelin Sun, 5 Mar 2017 18:25:19 +0000 (19:25 +0100)

Travis: also test on 32-bit Linux

When Git v2.9.1 was released, it had a bug that showed only on Windows
and on 32-bit systems: our assumption that `unsigned long` can hold
64-bit values turned out to be wrong.

This could have been caught earlier if we had a Continuous Testing
set up that includes a build and test run on 32-bit Linux.

Let's do this (and take care of the Windows build later). This patch
asks Travis CI to install a Docker image with 32-bit libraries and then
goes on to build and test Git using this 32-bit setup.

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

http: release strbuf on disabled alternatesEric Wong Sat, 4 Mar 2017 01:50:16 +0000 (01:50 +0000)

http: release strbuf on disabled alternates

This likely has no real-world impact on memory usage,
but it is cleaner for future readers.

Fixes: abcbdc03895f ("http: respect protocol.*.allow=user for http-alternates")
Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http: inform about alternates-as-redirects behaviorEric Wong Sat, 4 Mar 2017 08:36:45 +0000 (08:36 +0000)

http: inform about alternates-as-redirects behavior

It is disconcerting for users to not notice the behavior
change in handling alternates from commit cb4d2d35c4622ec2
("http: treat http-alternates like redirects")

Give the user a hint about the config option so they can
see the URL and decide whether or not they want to enable
http.followRedirects in their config.

Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7006: replace dubious testJohannes Schindelin Fri, 3 Mar 2017 17:32:01 +0000 (18:32 +0100)

t7006: replace dubious test

The idea of the test case "git -p - core.pager is not used from
subdirectory" was to verify that the setup_git_directory() function had
not been called just to obtain the core.pager setting.

However, we are about to fix the early config machinery so that it
*does* work, without messing up the global state.

Once that is done, the core.pager setting *will* be used, even when
running from a subdirectory, and that is a Good Thing.

The intention of that test case, however, was to verify that the
setup_git_directory() function has not run, because it changes global
state such as the current working directory.

To keep that spirit, but fix the incorrect assumption, this patch
replaces that test case by a new one that verifies that the pager is
run in the subdirectory, i.e. that the current working directory has
not been changed at the time the pager is configured and launched, even
if the `rev-parse` command requires a .git/ directory and *will* change
the working directory.

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

p7000: add test for filter-branch with --prune-emptyDevin J. Pohly Thu, 23 Feb 2017 08:27:36 +0000 (02:27 -0600)

p7000: add test for filter-branch with --prune-empty

Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

filter-branch: fix --prune-empty on parentless commitsDevin J. Pohly Thu, 23 Feb 2017 08:27:35 +0000 (02:27 -0600)

filter-branch: fix --prune-empty on parentless commits

Previously, the git_commit_non_empty_tree function would always pass any
commit with no parents to git-commit-tree, regardless of whether the
tree was nonempty. The new commit would then be recorded in the
filter-branch revision map, and subsequent commits which leave the tree
untouched would be correctly filtered.

With this change, parentless commits with an empty tree are correctly
pruned, and an empty file is recorded in the revision map, signifying
that it was rewritten to "no commits." This works naturally with the
parent mapping for subsequent commits.

Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7003: ensure --prune-empty removes entire branch when... Devin J. Pohly Thu, 23 Feb 2017 08:27:34 +0000 (02:27 -0600)

t7003: ensure --prune-empty removes entire branch when applicable

Sanity check before changing the logic in git_commit_non_empty_tree.

Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7003: ensure --prune-empty can prune root commitDevin J. Pohly Thu, 23 Feb 2017 08:27:33 +0000 (02:27 -0600)

t7003: ensure --prune-empty can prune root commit

New test to expose a bug in filter-branch whereby the root commit is
never pruned, even though its tree is empty and --prune-empty is given.

The setup isn't exactly pretty, but I couldn't think of a simpler way to
create a parallel commit graph sans the first commit.

Signed-off-by: Devin J. Pohly <djpohly@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

line-log.c: prevent crash during union of too many... Allan Xavier Thu, 2 Mar 2017 17:29:02 +0000 (17:29 +0000)

line-log.c: prevent crash during union of too many ranges

The existing implementation of range_set_union does not correctly
reallocate memory, leading to a heap overflow when it attempts to union
more than 24 separate line ranges.

For struct range_set *out to grow correctly it must have out->nr set to
the current size of the buffer when it is passed to range_set_grow.
However, the existing implementation of range_set_union only updates
out->nr at the end of the function, meaning that it is always zero
before this. This results in range_set_grow never growing the buffer, as
well as some of the union logic itself being incorrect as !out->nr is
always true.

The reason why 24 is the limit is that the first allocation of size 1
ends up allocating a buffer of size 24 (due to the call to alloc_nr in
ALLOC_GROW). This goes some way to explain why this hasn't been
caught before.

Fix the problem by correctly updating out->nr after reallocating the
range_set. As this results in out->nr containing the same value as the
variable o, replace o with out->nr as well.

Finally, add a new test to help prevent the problem reoccurring in the
future. Thanks to Vegard Nossum for writing the test.

Signed-off-by: Allan Xavier <allan.x.xavier@oracle.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

contrib: git-remote-{bzr,hg} placeholders don't need... Sebastian Schuberth Fri, 3 Mar 2017 10:57:46 +0000 (10:57 +0000)

contrib: git-remote-{bzr,hg} placeholders don't need Python

It does not make sense for these placeholder scripts to depend on Python
just because the real scripts do. At the example of Git for Windows, we
would not even be able to see those warnings as it does not ship with
Python. So just use plain shell scripts instead.

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/perf: add fallback for pre-bin-wrappers versions... Jeff King Fri, 3 Mar 2017 07:36:33 +0000 (02:36 -0500)

t/perf: add fallback for pre-bin-wrappers versions of git

It's tempting to say:

./run v1.0.0 HEAD

to see how we've sped up Git over the years. Unfortunately,
this doesn't quite work because versions of Git prior to
v1.7.0 lack bin-wrappers, so our "run" script doesn't
correctly put them in the PATH.

Worse, it means we silently find whatever other "git" is in
the PATH, and produce test results that have no bearing on
what we asked for.

Let's fallback to the main git directory when bin-wrappers
isn't present. Many modern perf scripts won't run with such
an antique version of Git, of course, but at least those
failures are detected and reported (and you're free to write
a limited perf script that works across many versions).

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

t/perf: use $MODERN_GIT for all repo-copying stepsJeff King Fri, 3 Mar 2017 07:14:03 +0000 (02:14 -0500)

t/perf: use $MODERN_GIT for all repo-copying steps

Since 1a0962dee (t/perf: fix regression in testing older
versions of git, 2016-06-22), we point "$MODERN_GIT" to a
copy of git that matches the t/perf script itself, and which
can be used for tasks outside of the actual timings. This is
needed because the setup done by perf scripts keeps moving
forward in time, and may use features that the older
versions of git we are testing do not have.

That commit used $MODERN_GIT to fix a case where we relied
on the relatively recent --git-path option. But if you go
back further still, there are more problems.

Since 7501b5921 (perf: make the tests work in worktrees,
2016-05-13), we use "git -C", but versions of git older than
44e1e4d67 (git: run in a directory given with -C option,
2013-09-09) don't know about "-C". So testing an old version
of git with a new version of t/perf will fail the setup
step.

We can fix this by using $MODERN_GIT during the setup;
there's no need to use the antique version, since it doesn't
affect the timings. Likewise, we'll adjust the "init"
invocation; antique versions of git called this "init-db".

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

t/perf: export variable used in other blocksJonathan Tan Thu, 2 Mar 2017 19:50:41 +0000 (11:50 -0800)

t/perf: export variable used in other blocks

In p0001, a variable was created in a test_expect_success block to be
used in later test_perf blocks, but was not exported. This caused the
variable to not appear in those blocks (this can be verified by writing
'test -n "$commit"' in those blocks), resulting in a slightly different
invocation than what was intended. Export that variable.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: improve description for core.quotePathAndreas Heiduk Thu, 2 Mar 2017 19:03:52 +0000 (20:03 +0100)

Documentation: improve description for core.quotePath

Linking the description for pathname quoting to the configuration
variable "core.quotePath" removes inconstistent and incomplete
sections while also giving two hints how to deal with it: Either with
"-c core.quotePath=false" or with "-z".

Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: add specific error for fetching an unadvert... Matt McCutchen Wed, 22 Feb 2017 16:05:57 +0000 (11:05 -0500)

fetch-pack: add specific error for fetching an unadvertised object

Enhance filter_refs (which decides whether a request for an unadvertised
object should be sent to the server) to record a new match status on the
"struct ref" when a request is not allowed, and have
report_unmatched_refs check for this status and print a special error
message, "Server does not allow request for unadvertised object".

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch_refs_via_pack: call report_unmatched_refsMatt McCutchen Wed, 22 Feb 2017 16:02:15 +0000 (11:02 -0500)

fetch_refs_via_pack: call report_unmatched_refs

"git fetch" currently doesn't bother to check that it got all refs it
sought, because the common case of requesting a nonexistent ref triggers
a die() in get_fetch_map. However, there's at least one case that
slipped through: "git fetch REMOTE SHA1" if the server doesn't allow
requests for unadvertised objects. Make fetch_refs_via_pack (which is
on the "git fetch" code path) call report_unmatched_refs so that we at
least get an error message in that case.

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: move code to report unmatched refs to a... Matt McCutchen Wed, 22 Feb 2017 16:01:22 +0000 (11:01 -0500)

fetch-pack: move code to report unmatched refs to a function

Prepare to reuse this code in transport.c for "git fetch".

While we're here, internationalize the existing error message.

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout: restrict @-expansions when finding branchJeff King Thu, 2 Mar 2017 08:23:18 +0000 (03:23 -0500)

checkout: restrict @-expansions when finding branch

When we parse "git checkout $NAME", we try to interpret
$NAME as a local branch-name. If it is, then we point HEAD
to that branch. Otherwise, we detach the HEAD at whatever
commit $NAME points to.

We do the interpretation by calling strbuf_branchname(), and
then blindly sticking "refs/heads/" on the front. This leads
to nonsense results when expansions like "@{upstream}" or
"@" point to something besides a local branch. We end up
with a local branch name like "refs/heads/origin/master" or
"refs/heads/HEAD".

Normally this has no user-visible effect because those
branches don't exist, and so we fallback to feeding the
result to get_sha1(), which resolves them correctly.

But as the new test in t3204 shows, there are corner cases
where the effect is observable, and we check out the wrong
local branch rather than detaching to the correct one.

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

strbuf_check_ref_format(): expand only local branchesJeff King Thu, 2 Mar 2017 08:23:14 +0000 (03:23 -0500)

strbuf_check_ref_format(): expand only local branches

This function asks strbuf_branchname() to expand any @-marks
in the branchname, and then we blindly stick refs/heads/ in
front of the result. This is obviously nonsense if the
expansion is "HEAD" or a ref in refs/remotes/.

The most obvious end-user effect is that creating or
renaming a branch with an expansion may have confusing
results (e.g., creating refs/heads/origin/master from
"@{upstream}" when the operation should be disallowed).

We can fix this by telling strbuf_branchname() that we are
only interested in local expansions. Any unexpanded bits are
then fed to check_ref_format(), which either disallows them
(in the case of "@{upstream}") or lets them through
("refs/heads/@" is technically valid, if a bit silly).

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

branch: restrict @-expansions when deletingJeff King Thu, 2 Mar 2017 08:23:10 +0000 (03:23 -0500)

branch: restrict @-expansions when deleting

We use strbuf_branchname() to expand the branch name from
the command line, so you can delete the branch given by
@{-1}, for example. However, we allow other nonsense like
"@", and we do not respect our "-r" flag (so we may end up
deleting an oddly-named local ref instead of a remote one).

We can fix this by passing the appropriate "allowed" flag to
strbuf_branchname().

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

t3204: test git-branch @-expansion corner casesJeff King Thu, 2 Mar 2017 08:23:06 +0000 (03:23 -0500)

t3204: test git-branch @-expansion corner cases

git-branch feeds the branch names from the command line to
strbuf_branchname(), but we do not yet tell that function
which kinds of expansions should be allowed. Let's create a
set of tests that cover both the allowed and disallowed
cases.

That shows off some breakages where we currently create or
delete the wrong ref (and will make sure that we do not
break any cases that _should_ be working when we do add more
restrictions).

Note that we check branch creation and deletion, but do not
bother with renames. Those follow the same code path as
creation.

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

interpret_branch_name: allow callers to restrict expansionsJeff King Thu, 2 Mar 2017 08:23:01 +0000 (03:23 -0500)

interpret_branch_name: allow callers to restrict expansions

The interpret_branch_name() function converts names like
@{-1} and @{upstream} into branch names. The expanded ref
names are not fully qualified, and may be outside of the
refs/heads/ namespace (e.g., "@" expands to "HEAD", and
"@{upstream}" is likely to be in "refs/remotes/").

This is OK for callers like dwim_ref() which are primarily
interested in resolving the resulting name, no matter where
it is. But callers like "git branch" treat the result as a
branch name in refs/heads/. When we expand to a ref outside
that namespace, the results are very confusing (e.g., "git
branch @" tries to create refs/heads/HEAD, which is
nonsense).

Callers can't know from the returned string how the
expansion happened (e.g., did the user really ask for a
branch named "HEAD", or did we do a bogus expansion?). One
fix would be to return some out-parameters describing the
types of expansion that occurred. This has the benefit that
the caller can generate precise error messages ("I
understood @{upstream} to mean origin/master, but that is a
remote tracking branch, so you cannot create it as a local
name").

However, out-parameters make the function interface somewhat
cumbersome. Instead, let's do the opposite: let the caller
tell us which elements to expand. That's easier to pass in,
and none of the callers give more precise error messages
than "@{upstream} isn't a valid branch name" anyway (which
should be sufficient).

The strbuf_branchname() function needs a similar parameter,
as most of the callers access interpret_branch_name()
through it.

We can break the callers down into two groups:

1. Callers that are happy with any kind of ref in the
result. We pass "0" here, so they continue to work
without restrictions. This includes merge_name(),
the reflog handling in add_pending_object_with_path(),
and substitute_branch_name(). This last is what powers
dwim_ref().

2. Callers that have funny corner cases (mostly in
git-branch and git-checkout). These need to make use of
the new parameter, but I've left them as "0" in this
patch, and will address them individually in follow-on
patches.

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

strbuf_branchname: add docstringJeff King Thu, 2 Mar 2017 08:21:30 +0000 (03:21 -0500)

strbuf_branchname: add docstring

This function and its companion, strbuf_check_branch_ref(),
did not have their purpose or semantics explained. Let's do
so.

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

strbuf_branchname: drop return valueJeff King Thu, 2 Mar 2017 08:21:27 +0000 (03:21 -0500)

strbuf_branchname: drop return value

The return value from strbuf_branchname() is confusing and
useless: it's 0 if the whole name was consumed by an @-mark,
but otherwise is the length of the original name we fed.

No callers actually look at the return value, so let's just
get rid of it.

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

interpret_branch_name: move docstring to header fileJeff King Thu, 2 Mar 2017 08:21:23 +0000 (03:21 -0500)

interpret_branch_name: move docstring to header file

We generally put docstrings with function declarations,
because it's the callers who need to know how the function
works. Let's do so for interpret_branch_name().

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

interpret_branch_name(): handle auto-namelen for @{-1}Jeff King Mon, 27 Feb 2017 09:25:40 +0000 (04:25 -0500)

interpret_branch_name(): handle auto-namelen for @{-1}

The interpret_branch_name() function takes a ptr/len pair
for the name, but you can pass "0" for "namelen", which will
cause it to check the length with strlen().

However, before we do that auto-namelen magic, we call
interpret_nth_prior_checkout(), which gets fed the bogus
"0". This was broken by 8cd4249c4 (interpret_branch_name:
always respect "namelen" parameter, 2014-01-15). Though to
be fair to that commit, it was broken in the _opposite_
direction before, where we would always treat "name" as a
string even if a length was passed.

You can see the bug with "git log -g @{-1}". That code path
always passes "0", and without this patch it cannot figure
out which branch's reflog to show.

We can fix it by a small reordering of the code.

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