repack_without_ref(): write peeled refs in the rewritten file
When a reference that existed in the packed-refs file is deleted, the
packed-refs file must be rewritten. Previously, the file was
rewritten without any peeled refs, even if the file contained peeled
refs when it was read. This was not a bug, because the packed-refs
file header didn't claim that the file contained peeled values. But
it had a performance cost, because the repository would lose the
benefit of having precomputed peeled references until pack-refs was
run again.
Teach repack_without_ref() to write peeled refs to the packed-refs
file (regardless of whether they were present in the old version of
the file).
This means that if the old version of the packed-refs file was not
fully peeled, then repack_without_ref() will have to peel references.
To avoid the expense of reading lots of loose references, we take two
shortcuts relative to pack-refs:
* If the peeled value of a reference is already known (i.e., because
it was read from the old version of the packed-refs file), then
output that peeled value again without any checks. This is the
usual code path and should avoid any noticeable overhead. (This is
different than pack-refs, which always re-peels references.)
* We don't verify that the packed ref is still current. It could be
that a packed references is overridden by a loose reference, in
which case the packed ref is no longer needed and might even refer
to an object that has been garbage collected. But we don't check;
instead, we just try to peel all references. If peeling is
successful, the peeled value is written out (even though it might
not be needed any more); if not, then the reference is silently
omitted from the output.
The extra overhead of peeling references in repack_without_ref()
should only be incurred the first time the packed-refs file is written
by a version of Git that knows about the "fully-peeled" attribute.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3211: demonstrate loss of peeled refs if a packed ref is deleted
Add a test that demonstrates that the peeled values recorded in
packed-refs are lost if a packed ref is deleted. (The code in
repack_without_ref() doesn't even attempt to write peeled refs.) This
will be fixed in a moment.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a function remove_ref(), which removes a single entry from a
reference cache.
Use this function to reimplement repack_without_ref(). The old
version iterated over all refs, packing all of them except for the one
to be deleted, then discarded the entire packed reference cache. The
new version deletes the doomed reference from the cache *before*
iterating.
This has two advantages:
* the code for writing packed-refs becomes simpler, because it doesn't
have to exclude one of the references.
* it is no longer necessary to discard the packed refs cache after
deleting a reference: symbolic refs cannot be packed, so packed
references cannot depend on each other, so the rest of the packed
refs cache remains valid after a reference is deleted.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
search_ref_dir(): return an index rather than a pointer
Change search_ref_dir() to return the index of the sought entry (or -1
on error) rather than a pointer to the entry. This will make it more
natural to use the function for removing an entry from the list.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
repack_without_ref(): silence errors for dangling packed refs
Stop emitting an error message when deleting a packed reference if we
find another dangling packed reference that is overridden by a loose
reference. See the previous commit for a longer explanation of the
issue.
We have to be careful to make sure that the invalid packed reference
really *is* overridden by a loose reference; otherwise what we have
found is repository corruption, which we *should* report.
Please note that this approach is vulnerable to a race condition
similar to the race conditions already known to affect packed
references [1]:
* Process 1 tries to peel packed reference X as part of deleting
another packed reference. It discovers that X does not refer to a
valid object (because the object that it referred to has been
garbage collected).
* Process 2 tries to delete reference X. It starts by deleting the
loose reference X.
* Process 1 checks whether there is a loose reference X. There is not
(it has just been deleted by process 2), so process 1 reports a
spurious error "X does not point to a valid object!"
The worst case seems relatively harmless, and the fix is identical to
the fix that will be needed for the other race conditions (namely
holding a lock on the packed-refs file during *all* reference
deletions), so we leave the cleaning up of all of them as a future
project.
t3210: test for spurious error messages for dangling packed refs
A packed reference can be overridden by a loose reference, in which
case the packed reference is obsolete and is never used. The object
pointed to by such a reference can be garbage collected. Since d66da478f2, this could lead to the emission of a spurious error
message:
error: refs/heads/master does not point to a valid object!
The error is generated by repack_without_ref() if there is an obsolete
dangling packed reference in packed-refs when the packed-refs file has
to be rewritten due to the deletion of another packed reference. Add
a failing test demonstrating this problem and some passing tests of
related scenarios.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Establish an internal API for iterating over references, which gives
the callback functions direct access to the ref_entry structure
describing the reference. (Do not change the iteration API that is
exposed outside of the module.)
Define a new internal callback signature
int each_ref_entry_fn(struct ref_entry *entry, void *cb_data)
Change do_for_each_ref_in_dir() and do_for_each_ref_in_dirs() to
accept each_ref_entry_fn callbacks, and rename them to
do_for_each_entry_in_dir() and do_for_each_entry_in_dirs(),
respectively. Adapt their callers accordingly.
Add a new function do_for_each_entry() analogous to do_for_each_ref()
but using the new callback style.
Change do_one_ref() into an each_ref_entry_fn that does some
bookkeeping and then calls a wrapped each_ref_fn.
Reimplement do_for_each_ref() in terms of do_for_each_entry(), using
do_one_ref() as an adapter.
Please note that the responsibility for setting current_ref remains in
do_one_ref(), which means that current_ref is *not* set when iterating
over references via the new internal API. This is not a disadvantage,
because current_ref is not needed by callers of the internal API (they
receive a pointer to the current ref_entry anyway). But more
importantly, this change prevents peel_ref() from returning invalid
results in the following scenario:
When iterating via the external API, the iteration always includes
both packed and loose references, and in particular never presents a
packed ref if there is a loose ref with the same name. The internal
API, on the other hand, gives the option to iterate over only the
packed references. During such an iteration, there is no check
whether the packed ref might be hidden by a loose ref of the same
name. But until now the packed ref was recorded in current_ref during
the iteration. So if peel_ref() were called with the reference name
corresponding to current ref, it would return the peeled version of
the packed ref even though there might be a loose ref that peels to a
different value. This scenario doesn't currently occur in the code,
but fix it to prevent things from breaking in a very confusing way in
the future.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Peel the entry, and as a side effect store the peeled value in the
entry. Use this function from two places in peel_ref(); a third
caller will be added soon.
Please note that this change can lead to ref_entries for unpacked refs
being peeled. This has no practical benefit but is harmless.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
peel_ref(): fix return value for non-peelable, not-current reference
The old version was inconsistent: when a reference was
REF_KNOWS_PEELED but with a null peeled value, it returned non-zero
for the current reference but zero for other references. Change the
behavior for non-current references to match that of current_ref,
which is what callers expect. Document the behavior.
Current callers only call peel_ref() from within a for_each_ref-style
iteration and only for the current ref; therefore, the buggy code path
was never reached.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
peel_object(): give more specific information in return value
Instead of just returning a success/failure bit, return an enumeration
value that explains the reason for any failure. This will come in
handy shortly.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of copying the reference's SHA1 into a caller-supplied
variable, just return the ref_entry itself (or NULL if there is no
such entry). This change will allow the function to be used from
elsewhere.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rs/pp-user-info-without-extra-allocation:
pretty: remove intermediate strbufs from pp_user_info()
pretty: simplify output line length calculation in pp_user_info()
pretty: simplify input line length calculation in pp_user_info()
* tr/remote-tighten-commandline-parsing:
remote: 'show' and 'prune' can take more than one remote
remote: check for superfluous arguments in 'git remote add'
remote: add a test for extra arguments, according to docs
contrib/subtree: don't delete remote branches if split fails
When using "git subtree push" to split out a subtree and push it to a
remote repository, we do not detect if the split command fails which
causes the LHS of the refspec to be empty, deleting the remote branch.
Fix this by pulling the result of the split command into a variable so
that we can die if the command fails.
Reported-by: Steffen Jaeckel <steffen.jaeckel@stzedn.de> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Bazaar doesn't seem to be tested for multiple usage of branches, so
resources seem to be leaked all over. Let's try to minimize this by
accessing the Branch objects only when needed.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This way we don't need to store the list of all the revisions, which
doesn't seem to be very memory efficient with bazaar's design, for
whatever reason.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If part of the merge was already pushed, we don't have the blob_marks
available, however, the commits are already stored in bazaar, so we can
use the revision_tree to fetch the contents.
We want to do this only when there's no other option.
There's no easy way to test this.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the branches diverge we want to reset the pointer to where the remote
actually is. Since we can access remote branches just as easily as local
ones, let's do so.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In order to do that, we need to store the marks of every file, so that
they can be fetched when needed. Unfortunately we can't tell bazaar that
nothing changed, we need to send the data so that it can figure it out
by itself.
And since it will be requesting a bunch of information by the file_id,
it's better to have a helper dict (rev_files), so that we can fetch it
quickly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the !delta_data error path of unpack_entry(), we run free(base).
This became a window for use-after-free() in abe601b (sha1_file:
remove recursion in unpack_entry, 2013-03-27), as follows:
Before abe601b, we got the 'base' from cache_or_unpack_entry(..., 0);
keep_cache=0 tells it to also remove that entry. So the 'base' is at
this point not cached, and freeing it in the error path is the right
thing.
After abe601b, the structure changed: we use a three-phase approach
where phase 1 finds the innermost base or a base that is already in
the cache. In phase 3 we therefore know that all bases we unpack are
not part of the delta cache yet. (Observe that we pop from the cache
in phase 1, so this is also true for the very first base.) So we make
no further attempts to look up the bases in the cache, and just call
add_delta_base_cache() on every base object we have assembled.
But the !delta_data error path remained unchanged, and now calls
free() on a base that has already been entered in the cache. This
means that there is a use-after-free if we later use the same base
again.
So remove that free(); we are still going to use that data.
Reported-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t0008: use named pipe (FIFO) to test check-ignore streaming
sleeps in the check-ignore test suite are not ideal since they can
fail when the system is under load, or when a tool like valgrind is
used which drastically alters the timing. Therefore we replace them
with a more robust solution using a named pipe (FIFO).
Thanks to Jeff King for coming up with the redirection wizardry
required to make this work.
Most test results go in $TEST_OUTPUT_DIRECTORY, but the output files for
tests run with --tee or --valgrind just use bare "test-results".
Changes these so that they do respect $TEST_OUTPUT_DIRECTORY.
As a result of this, the valgrind/analyze.sh script may no longer
inspect the correct files so it is also updated to respect
$TEST_OUTPUT_DIRECTORY by adding it to GIT-BUILD-OPTIONS. This may be a
regression for people who have TEST_OUTPUT_DIRECTORY in their config.mak
but want to override it in the environment, but this change merely
brings it into line with GIT_TEST_OPTS which already cannot be
overridden if it is specified in config.mak.
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-completion.bash: add remote.pushdefault to config list
224c2171 (remote.c: introduce remote.pushdefault, 2013-04-02)
introduced the remote.pushdefault configuration variable, but forgot
to teach git-completion.bash about it. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-completion.bash: add branch.*.pushremote to config list
9f765ce (remote.c: introduce branch.<name>.pushremote, 2013-04-02)
introduced the configuration variable branch.*.pushremote, but forgot
to teach git-completion.bash about it. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
complete: zsh: use zsh completion for the main cmd
complete: zsh: trivial simplification
git-completion.bash: complete branch.*.rebase as boolean
git-completion.bash: add diff.submodule to config list
git-completion.bash: lexical sorting for diff.statGraphWidth
complete: zsh: use zsh completion for the main cmd
So that we can have a nice zsh completion output:
% git <tab>
add -- add file contents to the index
bisect -- find by binary search the change that introduced a bug
branch -- list, create, or delete branches
checkout -- checkout a branch or paths to the working tree
clone -- clone a repository into a new directory
commit -- record changes to the repository
diff -- show changes between commits, commit and working tree, etc
fetch -- download objects and refs from another repository
grep -- print lines matching a pattern
init -- create an empty Git repository or reinitialize an existing one
log -- show commit logs
merge -- join two or more development histories together
mv -- move or rename a file, a directory, or a symlink
pull -- fetch from and merge with another repository or a local branch
push -- update remote refs along with associated objects
rebase -- forward-port local commits to the updated upstream head
reset -- reset current HEAD to the specified state
rm -- remove files from the working tree and from the index
show -- show various types of objects
status -- show the working tree status
tag -- create, list, delete or verify a tag object signed with GPG
And other niceties, like 'git --git-dir=<tab>' showing only directories.
For the rest, the bash completion stuff is still used.
Also, add my copyright, since this more than a thin wrapper.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The only reason I wrapped this code around a sub-function is because zsh
did the same in it's bashcompinit script in order to declare the special
variable 'words' as hidden, but only in this context.
There's no need for that any more since we access __git_main directly,
so 'words' is not modified, so there's no need for the sub-function.
In zsh mode the array indexes are different though.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-completion.bash: complete branch.*.rebase as boolean
6fac1b83 (completion: add missing config variables, 2009-06-29) added
"rebase" to the list of completions for "branch.*.*", but forgot to
specify completions for the values that this configuration variable
can take (namely "false" and "true"). Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-completion.bash: add diff.submodule to config list
c47ef57 (diff: introduce diff.submodule configuration variable,
2012-11-13) introduced the diff.submodule configuration variable, but
forgot to teach git-completion.bash about it. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-completion.bash: lexical sorting for diff.statGraphWidth
df44483a (diff --stat: add config option to limit graph width,
2012-03-01) added the option diff.startGraphWidth to the list of
configuration variables in git-completion.bash, but failed to notice
that the list is sorted alphabetically. Move it to its rightful place
in the list.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git.pm: call tempfile from File::Temp as a regular function
We call File::Temp's "tempfile" function as a class method, but it was
never designed to be called this way. Older versions seemed to
tolerate it, but as of File::Temp 0.23, it blows up like this:
$ git svn fetch
'tempfile' can't be called as a method at .../Git.pm line 1117.
Fix it by calling it as a regular function, just inside the File::Temp
namespace.
Signed-off-by: H. Merijn Brand <h.m.brand@xs4all.nl> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack: ignore 'shallow' lines with unknown obj-ids
When the client sends a 'shallow' line for an object that the server does
not have, the server currently dies with the error: "did not find object
for shallow <obj-id>". The client may have truncated the history at
the commit by fetching shallowly from a different server, or the commit
may have been garbage collected by the server. In either case, this
unknown commit is not relevant for calculating the pack that is to be
sent and can be safely ignored, and it is not used when recomputing where
the updated history of the client is cauterised.
The documentation in technical/pack-protocol.txt has been updated to
remove the restriction that "Clients MUST NOT mention an obj-id which it
does not know exists on the server". This requirement is not realistic
because clients cannot know whether an object has been garbage collected
by the server.
Signed-off-by: Michael Heemskerk <mheemskerk@atlassian.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit d24fbca (Remove Git's support for smoke testing - 2011-12-23)
removed the smoke test support from the test suite but it was
re-added by commit 342e9ef (Introduce a performance testing
framework - 2012-02-17). This appears to be the result of a
mis-rebase, since re-adding the smoke testing infrastructure does
not relate to the subject of that commit.
The current 'smoke' target is broken since the 'harness' script it
uses no longer exists, so just reapply this section of commit d24fbca
and remove all of the smoke testing section in the makefile.
Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sparse issues 68 errors (two errors for each main() function) such
as the following:
SP git.c
git.c:510:5: error: too many arguments for function mingw_main
git.c:510:5: error: symbol 'mingw_main' redeclared with different type \
(originally declared at git.c:510) - different argument counts
The errors are caused by the 'main' macro used by the MinGW build
to provide a replacement main() function. The original main function
is effectively renamed to 'mingw_main' and is called from the new
main function. The replacement main is used to execute certain actions
common to all git programs on MinGW (e.g. ensure the standard I/O
streams are in binary mode).
In order to suppress the errors, we change the macro to include the
parameters in the declaration of the mingw_main function.
Unfortunately, this change provokes both sparse and gcc to complain
about 9 calls to mingw_main(), such as the following:
CC git.o
git.c: In function 'main':
git.c:510: warning: passing argument 2 of 'mingw_main' from \
incompatible pointer type
git.c:510: note: expected 'const char **' but argument is of \
type 'char **'
In order to suppress these warnings, since both of the main
functions need to be declared with the same prototype, we
change the declaration of the 9 main functions, thus:
int main(int argc, char **argv)
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
SP compat/mingw.c
compat/mingw.c:795:3: warning: symbol 'pinfo_t' was not declared. \
Should it be static?
compat/mingw.c:796:16: warning: symbol 'pinfo' was not declared. \
Should it be static?
compat/mingw.c:797:18: warning: symbol 'pinfo_cs' was not declared. \
Should it be static?
compat/mingw.c:1207:23: warning: Using plain integer as NULL pointer
In 'pinfo_t' variable, defined on line 795, seems to have been a
mistake (a missing typedef keyword?), so we simply remove it.
The 'pinfo' variable does not require more than file scope, so we
simply add the static modifier to the declaration.
The 'pinfo_cs' variable, in contrast, requires initialisation in the
mingw replacement main() function, so we add an extern declaration to
the compat/mingw.h header file.
The remaining warning is suppressed by replacing the rhs of the
pointer assignment with the NULL pointer literal.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sparse issues two 'Using plain integer as NULL pointer' warnings
against the call to the CreateFileMapping() function. The warnings
relate to the second and sixth parameters, which both have pointer
type. In order to suppress the warnings, we simply pass the NULL
pointer, rather than '0', to those parameters in the function call.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
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>
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>
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>
pretty: Fix bug in truncation support for %>, %< and %><
Some systems experience failures in t4205-*.sh (tests 18-20, 27)
which all relate to the use of truncation with the %< padding
placeholder. This capability was added in the commit a7f01c6b
("pretty: support truncating in %>, %< and %><", 19-04-2013).
The truncation support was implemented with the assistance of a
new strbuf function (strbuf_utf8_replace). This function contains
the following code:
Unfortunately, this code is subject to unspecified behaviour. In
particular, the order of evaluation of the argument expressions
(along with the associated side effects) is not specified by the
C standard. Note that the second argument expression is a call to
strbuf_detach() which, as a side effect, sets the 'len' and 'alloc'
fields of the sb_dst argument to zero. Depending on the order of
evaluation of the argument expressions to the strbuf_attach call,
this can lead to assigning an empty string to 'sb_src'.
In order to remove the undesired behaviour, we replace the above
line of code with:
Sparse issues an "'junk_mode' not declared. Should it be static?"
warning. In order to suppress the warning, since this symbol does
not need more than file visibility, we simply add the static
modifier to its declaration.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-tree: fix typo in "both changed identically"
Commit aacecc3 (merge-tree: don't print entries that match "local" -
2013-04-07) had a typo causing the "same in both" check to be incorrect
and check if both the base and "their" versions are removed instead of
checking that both the "our" and "their" versions are removed. Fix
this.
Reported-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Test-written-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
* rr/shortlog-doc:
builtin/shortlog.c: make usage string consistent with log
builtin/log.c: make usage string consistent with doc
git-shortlog.txt: make SYNOPSIS match log, update OPTIONS
git-log.txt: rewrite note on why "--" may be required
git-log.txt: generalize <since>..<until>
git-log.txt: order OPTIONS properly; move <since>..<until>
revisions.txt: clarify the .. and ... syntax
git-shortlog.txt: remove (-h|--help) from OPTIONS