t/Makefile: fix result handling with TEST_OUTPUT_DIRECTORY

When TEST_OUTPUT_DIRECTORY is set, the test results will be generated in
"$TEST_OUTPUT_DIRECTORY/test-results", which may not be the same as
"test-results" in t/Makefile.  This causes the aggregate-results target
to fail as it finds no count files.

Fix this by introducing TEST_RESULTS_DIRECTORY and using it wherever
test-results is referenced.

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

The commit fea16b4 (git-completion.bash: add support for path
completion) introduced quite a few changes, without the usual tests.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: document tilde expansion failure in tests

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

The only caller, __git_complete_index_file() doesn't specify any limits
to the options for 'git ls-files', neither should this function.

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

Like the rest of the script does; let's not access COMPREPLY directly.

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

At the end of the day what we really need is to find out the files that
have been staged, or modified, because those files are the ones that
make sense to pass as arguments to 'git commit'.

We need diff-index to find those out, since 'git ls-files' doesn't do
that.

But we don't need wrappers and wrappers basically identical to the ones
used for 'git ls-files', when we can pretend it receives a --committable
option that would return what we need.

That way, we can remove a bunch of code without any functional changes.

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

The calls to __gitcomp_file() are essentially the same, but with
different prefix.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: add hack to enable file mode in bash < 4

This way we don't need all the compat stuff, different filters, and so
on. Also, now we complete exactly the same in bash 3 and bash 4.

This is the way bash-completion did it for quite some time, when bash 3
was supported. For more information about the hack:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272660#64

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: add space after completed filename

Just like before fea16b4 (git-completion.bash: add support for path
completion).

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

Refactor the code into the only caller; __git_index_files().

Also, Somehow messing up with the 'path' variable messes up the 'PATH'
variable. So let's not do that.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
revision.c: tighten up TREESAME handling of merges

Historically TREESAME was set on a commit if it was TREESAME to _any_ of
its parents. This is not optimal, as such a merge could still be worth
showing, particularly if it is an odd "-s ours" merge that (possibly
accidentally) dropped a change. And the problem is further compounded by
the fact that simplify_merges could drop the actual parent that a commit
was TREESAME to, leaving it as a normal commit marked TREESAME that
isn't actually TREESAME to its remaining parent.

This commit redefines TREESAME to be true only if a commit is TREESAME to
_all_ of its parents. This doesn't affect either the default
simplify_history behaviour (because partially TREESAME merges are turned
into normal commits), or full-history with parent rewriting (because all
merges are output). But it does affect other modes.

It also modifies simplify_merges to recalculate TREESAME after removing
a parent. This is achieved by storing per-parent TREESAME flags on the
initial scan, so the combined flag can be easily recomputed.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
simplify-merges: never remove all TREESAME parents

In the event of an odd merge, we may find ourselves TREESAME to
apparently redundant parents. Prevent simplify_merges() from removing
every TREESAME parent - in the event of such a merge it's useful to see
where we came actually from came.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
simplify-merges: drop merge from irrelevant side branch

Reimplement commit 4b7f53da on top of the new simplify-merges
infrastructure, tightening the condition to only consider root parents;
the original version incorrectly dropped parents that were TREESAME to
anything.

Original log message follows.

The merge simplification rule stated in 6546b59 (revision traversal:
show full history with merge simplification, 2008-07-31) still
treated merge commits too specially.  Namely, in a history with this
shape:

	---o---o---M
	          /
         x---x---x

where three 'x' were on a history completely unrelated to the main
history 'o' and do not touch any of the paths we are following, we
still said that after simplifying all of the parents of M, 'x'
(which is the leftmost 'x' that rightmost 'x simplifies down to) and
'o' (which would be the last commit on the main history that touches
the paths we are following) are independent from each other, and
both need to be kept.

That is incorrect; when the side branch 'x' never touches the paths,
it should be removed to allow M to simplify down to the last commit
on the main history that touches the paths.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/regex/regexec.c: Fix some sparse warnings

Sparse issues an "Using plain integer as NULL pointer" warning along
with two "symbol was not declared. Should it be static?" type warnings
for the 'merge_state_with_log' and 'find_recover_state' functions.

In order to suppress the warnings, we replace the use of '0' as a null
pointer constant with NULL and add the static modifier to the function
definitions.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/fnmatch/fnmatch.c: Fix a sparse error

Sparse issues the following error and warnings:

    SP compat/fnmatch/fnmatch.c
.../fnmatch.c:144:17: warning: Using plain integer as NULL pointer
.../fnmatch.c:238:67: warning: Using plain integer as NULL pointer
.../fnmatch.c:303:40: error: too many arguments for function getenv

The error is caused by the extern declaration for the getenv function
not including the function prototype. Without the prototype, sparse
effectively sees the declaration as 'char *getenv(void)'. In order to
suppress the error, we simply include the function prototype.

In order to suppress the warnings, we include the <stddef.h> header
which provides an appropriate definition of the NULL macro, rather
than using the (inappropriate) default definition at fnmatch.c:132.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/nedmalloc: Fix some sparse warnings

Sparse issues many "Using plain integer as NULL pointer" warnings
while checking nedmalloc.c (at least 98 such warnings before giving
up due to "too many warnings"). In addition, sparse issues some
"non-ANSI function declaration" type warnings for the symbols
'win32_getcurrentthreadid', 'malloc_stats' and 'malloc_footprint'.

In order to suppress the NULL pointer warnings, rather than replace
all uses of '0' as a null pointer representation with NULL, we add
-Wno-non-pointer-null to SPARSE_FLAGS while checking nedmalloc.c.

In order to suppress the "non-ANSI function declaration" warnings,
we simply include the missing 'empty parameter list' prototype (void)
in the function declarations.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/nedmalloc: Fix compiler warnings on linux

On linux, when the build variable USE_NED_ALLOCATOR is set, gcc
issues the following warnings:

    In file included from compat/nedmalloc/nedmalloc.c:63:
    .../malloc.c.h: In function 'mmap_resize':
    .../malloc.c.h:3762: warning: implicit declaration of function 'mremap'
    .../malloc.c.h: In function 'sys_trim':
    .../malloc.c.h:4195: warning: comparison between pointer and integer

The warnings are caused by the <sys/mman.h> header not enabling the
(conditional) declaration of the mremap() function.  The declaration
can be enabled by defining the _GNU_SOURCE symbol prior to including
certain system header files. In particular, it may not be sufficient
to simply define _GNU_SOURCE just prior to including the <sys/mman.h>
header. (e.g. defining the symbol after including <sys/types.h> will
be completely ineffective.)

In order to suppress the warnings, we define the _GNU_SOURCE symbol
at the start of the malloc.c.h header file.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/unsetenv.c: Fix a sparse warning

The gitunsetenv function includes an (redundant) declaration of the
'environ' symbol, which is a pointer to the table of environment
variables. Unfortunately, on MinGW, this provokes sparse to issue
the following warning:

    compat/unsetenv.c:5:20: warning: non-ANSI function declaration of \
    function '__p__environ'

On MinGW, the <stdlib.h> header defines the 'environ' symbol as a
preprocessor macro (via _environ) which obtains the environ table
pointer via a call to the __p__environ() function.

In order to suppress the warning, we simply remove the redundant
declaration of the 'environ' symbol, since the symbol is already
declared correctly in <stdlib.h> (included via git-compat-util.h).

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/win32/pthread.c: Fix a sparse warning

Sparse issues a 'Using plain integer as NULL pointer' warning when
initializing an pthread_t structure with an '{ 0 }' initializer.
The first field of the pthread_t structure has type HANDLE (void *),
so in order to suppress the warning, we replace the initializer
expression with '{ NULL }'.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/poll/poll.c: Fix a sparse warning

Sparse issues an 'Using plain integer as NULL pointer' warning when
passing the constant '0' as the second parameter in the call to the
WSAEventSelect() function. The function parameter has a pointer type
(WSAEVENT, aka HANDLE, aka void *) so that, in order to suppress the
warning, we simply pass NULL for that parameter in the function call
expression.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>