Makefile: move the setting of *FLAGS closer to "include"
Move the setting of variables like CFLAGS down past settings like
"prefix" and default programs like "TAR" to just before we do the
include from "config.mak.*".
There's no functional changes here yet, but move note that
"ALL_CFLAGS" and "ALL_LDFLAGS" are moved below the include. A
follow-up change will tweak those depending on a variable set in
config.mak.dev.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
Move the assignment of the "STRIP" variable down to where we're
setting variables with the names of other programs.
For consistency with those use "=" for the assignment instead of
"?=". I can't imagine why this would need to be different than the
rest, and 4dc00021f7 ("Makefile: add 'strip' target", 2006-01-12)
which added it doesn't provide an explanation.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
Remove a comment referring to a caveat that hasn't been applicable
since 18b0fc1ce1 ("Git.pm: Kill Git.xs for now", 2006-09-23).
At the time of 8d7f586f13 ("Git.pm: Support for perl/ being built by a
different compiler", 2006-06-25) some of the code in perl would be
built by a C compiler, but support for that went away a few months
later in 18b0fc1ce1 discussed above.
Since my 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple
make rules", 2017-12-10) the perl/ directory doesn't even have its own
build process.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Sat, 16 Feb 2019 06:57:56 +0000 (01:57 -0500)]
diff: reuse diff setup for --no-index case
When "--no-index" is in effect (or implied by the arguments), git-diff
jumps early to a special code path to perform that diff. This means we
miss out on some settings like enabling --ext-diff and --textconv by
default.
Let's jump to the no-index path _after_ we've done more setup on
rev.diffopt. Since some of the options don't affect us (e.g., items
related to the index), let's re-order the setup into two blocks (see the
in-code comments).
Note that we also need to stop re-initializing the diffopt struct in
diff_no_index(). This should not be necessary, as it will already have
been initialized by cmd_diff() (and there are no other callers). That in
turn lets us drop the "repository" argument from diff_no_index (which
never made much sense, since the whole point is that you don't need a
repository).
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
During the six months of development of the Azure Pipelines support, the
patches went through quite a few iterations of changes, and to test
those iterations, a temporary build definition was used.
In the meantime, Azure Pipelines support made it to `master`, and we now
have a regular Azure Pipeline, installed via the common GitHub App
workflow. This new pipeline has a different name (git.git instead of
test-git.git), and a new ID (11 instead of 2).
Let's adjust the badge in our README to reflect that final shape of the
Azure Pipeline.
Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
Derrick Stolee [Fri, 22 Feb 2019 22:25:07 +0000 (14:25 -0800)]
trace2:data: pack-objects: add trace2 regions
When studying the performance of 'git push' we would like to know
how much time is spent at various parts of the command. One area
that could cause performance trouble is 'git pack-objects'.
Add trace2 regions around the three main actions taken in this
command:
Jeff Hostetler [Fri, 22 Feb 2019 22:25:03 +0000 (14:25 -0800)]
trace2:data: add trace2 regions to wt-status
Add trace2_region_enter() and trace2_region_leave() calls around the
various phases of a status scan. This gives elapsed time for each
phase in the GIT_TR2_PERF and GIT_TR2_EVENT trace target.
Also, these Trace2 calls now use s->repo rather than the_repository.
Signed-off-by: Jeff Hostetler <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff Hostetler [Fri, 22 Feb 2019 22:25:01 +0000 (14:25 -0800)]
trace2: create new combined trace facility
Create a new unified tracing facility for git. The eventual intent is to
replace the current trace_printf* and trace_performance* routines with a
unified set of git_trace2* routines.
In addition to the usual printf-style API, trace2 provides higer-level
event verbs with fixed-fields allowing structured data to be written.
This makes post-processing and analysis easier for external tools.
Trace2 defines 3 output targets. These are set using the environment
variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT". These may be
set to "1" or to an absolute pathname (just like the current GIT_TRACE).
* GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command
summary data.
* GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE.
It extends the output with columns for the command process, thread,
repo, absolute and relative elapsed times. It reports events for
child process start/stop, thread start/stop, and per-thread function
nesting.
* GIT_TR2_EVENT is a new structured format. It writes event data as a
series of JSON records.
Calls to trace2 functions log to any of the 3 output targets enabled
without the need to call different trace_printf* or trace_performance*
routines.
Signed-off-by: Jeff Hostetler <redacted> Signed-off-by: Junio C Hamano <redacted>
This is git-checy-racy command, added a long time ago [1] and was never
part of the default build. Naturally after some makefile changes [2],
git-check-racy was no longer recognized as a build target. Even if it
compiles to day, it will not link after the introduction of
common-main.c [3].
Racy index has not been a problem for a long time [4]. It's time to let
this code go. I briefly consider if check-racy should be part of
test-tool. But I don't think it's worth the effort.
[1] 42f774063d (Add check program "git-check-racy" - 2006-08-15)
[2] c373991375 (Makefile: list generated object files in OBJECTS -
2010-01-26)
[3] 3f2e2297b9 (add an extra level of indirection to main() -
2016-07-01)
[4] I pretend I don't remember anything about the recent split-index's
racy problem
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted> Signed-off-by: Junio C Hamano <redacted>
Use the recently split-up components of the corrupt_graph_and_verify()
function to assert that we error on graphs that are too small. The
error was added in 2a2e32bdc5 ("commit-graph: implement git
commit-graph read", 2018-04-10), but there was no test for it.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
commit-graph tests: split up corrupt_graph_and_verify()
Split up the corrupt_graph_and_verify() function added in d9b9f8a6fd ("commit-graph: verify catches corrupt signature",
2018-06-27) into its logical components of setting up the test itself,
doing the corruption in a particular way with "dd", and then finally
testing that stderr is what we expect.
This allows for re-using everything except the now slimmer
corrupt_graph_and_verify() to corrupt the graph in a way that doesn't
involve inserting a given byte sequence at a given position,
e.g. truncating it entirely to a custom value.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
Jonathan Tan [Thu, 21 Feb 2019 20:24:40 +0000 (12:24 -0800)]
remote-curl: refactor reading into rpc_state's buf
Currently, whenever remote-curl reads pkt-lines from its response file
descriptor, only the payload is written to its buf, not the 4 characters
denoting the length. A future patch will require the ability to also
write those 4 characters, so in preparation for that, refactor this read
into its own function.
Signed-off-by: Jonathan Tan <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Fri, 22 Feb 2019 19:26:43 +0000 (11:26 -0800)]
format-patch: notice failure to open cover letter for writing
The make_cover_letter() function is supposed to open a new file for
writing, and let the caller write into it via FILE *rev->diffopt.file
but because the function does not return anything, the caller does not
bother checking the return value.
Make sure it dies, instead of keep going with a NULL output
filestream and relying on it to cause a crash, when it fails to
open the file.
Change an unportable invocation of "dd" with count=0, that wanted to
truncate the commit-graph file. In POSIX it is unspecified what
happens when count=0 is provided[1]. The NetBSD "dd" behavior
differs from GNU (and seemingly other BSDs), which has left this test
broken since d2b86fbaa1 ("commit-graph: fix buffer read-overflow",
2019-01-15).
Copying from /dev/null would seek/truncate to seek=$zero_pos and
stop immediately after that (without being able to copy anything),
which is the right way to truncate the file.
Fix widely supported but non-POSIX basic regex syntax introduced in
[1] and [2]. On GNU, NetBSD and FreeBSD the following works:
$ echo xy >f
$ grep 'xy\?' f; echo $?
xy
0
The same goes for "\+". The "?" and "+" syntax is not in the BRE
syntax, just in ERE, but on some implementations it can be invoked by
prefixing the meta-operator with "\", but not on OpenBSD:
Josh Steadmon [Wed, 20 Feb 2019 00:32:26 +0000 (16:32 -0800)]
protocol-capabilities.txt: document symref
In 7171d8c15f ("upload-pack: send symbolic ref information as
capability"), we added a symref capability to the pack protocol, but it
was never documented. Adapt the patch notes from that commit and add
them to the capabilities documentation.
While we're at it, add a disclaimer to the top of
protocol-capabilities.txt noting that the doc only applies to v0/v1 of
the wire protocol.
Signed-off-by: Josh Steadmon <redacted> Signed-off-by: Junio C Hamano <redacted>
Elijah Newren [Thu, 21 Feb 2019 17:50:29 +0000 (09:50 -0800)]
merge-options.txt: correct wording of --no-commit option
The former wording implied that --no-commit would always cause the
merge operation to "pause" and allow the user to make further changes
and/or provide a special commit message for the merge commit. This
is not the case for fast-forward merges, as there is no merge commit
to create. Without a merge commit, there is no place where it makes
sense to "stop the merge and allow the user to tweak changes"; doing
that would require a full rebase of some sort.
Since users may be unaware of whether their branches have diverged or
not, modify the wording to correctly address fast-forward cases as well
and suggest using --no-ff with --no-commit if the point is to ensure
that the merge stops before completing.
Reported-by: Ulrich Windl <redacted> Signed-off-by: Elijah Newren <redacted> Signed-off-by: Junio C Hamano <redacted>
Robert P. J. Day [Wed, 20 Feb 2019 07:53:54 +0000 (02:53 -0500)]
mention use of "hooks.allownonascii" in "man githooks"
The default pre-commit script checks the config variable
"hooks.allownonascii" to determine whether to allow non-ASCII file
names -- mention this in "man githooks", just as the section on
"update" mentions the use of "hooks.allowunannotated".
Signed-off-by: Robert P. J. Day <redacted> Signed-off-by: Junio C Hamano <redacted>
The resolve_ref_unsafe() function can, and sometimes will in the case
of this codepath, return the char * passed to it to the caller. In
this case we construct a strbuf, free it, and then continue using the
dst_name after that free().
The code being fixed dates back to da3efdb17b ("receive-pack: detect
aliased updates which can occur with symrefs", 2010-04-19). When it
was originally added it didn't have this bug, it was introduced when
it was subsequently modified to use strbuf in 6b01ecfe22 ("ref
namespaces: Support remote repositories via upload-pack and
receive-pack", 2011-07-08).
This is theoretically a security issue, the C standard makes no
guarantees that a value you use after free() hasn't been poked at or
changed by something else on the system, but in practice modern OSs
will have mapped the relevant page to this process, so nothing else
would have used it. We do no further allocations between the free()
and use-after-free, so we ourselves didn't corrupt or change the
value.
Jeff investigated that and found: "It probably would be an issue if
the allocation were larger. glibc at least will use mmap()/munmap()
after some cutoff[1], in which case we'd get a segfault from hitting
the unmapped page. But for small allocations, it just bumps brk() and
the memory is still available for further allocations after
free(). [...] If you had a sufficiently large refname you might be
able to trigger the bug [...]. I tried to push such a ref. I had to
manually make a packed-refs file with the long name to avoid
filesystem limits (though probably you could have a long a/b/c/ name
on ext4). But the result can't actually be pushed, because it all has
to fit into a 64k pkt-line as part of the push protocol.".
An a alternative and more succinct way of implementing this would have
been to do the strbuf_release() at the end of check_aliased_update()
and use "goto out" instead of the early "return" statements. Hopefully
this approach of using a helper instead makes it easier to follow.
1. Jeff: "Weirdly, the mmap() cutoff on my glibc system is 135168
bytes. Which is...2^17 + 2^12? 33 pages? I'm sure there's a good
reason for that, but I didn't dig into it."
Reported-by: 王健强 <redacted> Helped-by: Jeff King <redacted> Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
This adds value completion for a couple more paramters. To make it
easier to maintain these hard coded lists, add a comment at the original
list/code to remind people to update git-completion.bash too.
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted> Signed-off-by: Junio C Hamano <redacted>
* mk/t5562-no-input-to-too-large-an-input-test:
t5562: do not depend on /dev/zero
Revert "t5562: replace /dev/zero with a pipe from generate_zero_bytes"
Max Kirillov [Sat, 24 Nov 2018 09:37:19 +0000 (11:37 +0200)]
t5562: do not reuse output files
Some expected failures of git-http-backend leaves running its children
(receive-pack or upload-pack) which still hold opened descriptors
to act.err and with some probability they live long enough to write
there their failure messages after next test has already truncated
the files. This causes occasional failures of the test script.
Avoid the issue by using separated output and error file for each test,
apprending the test number to their name.
Reported-by: Carlo Arenas <redacted> Helped-by: Carlo Arenas <redacted> Helped-by: Junio C Hamano <redacted> Signed-off-by: Max Kirillov <redacted> Signed-off-by: Junio C Hamano <redacted>
tests: teach the test-tool to generate NUL bytes and use it
In cc95bc2025 (t5562: replace /dev/zero with a pipe from
generate_zero_bytes, 2019-02-09), we replaced usage of /dev/zero (which
is not available on NonStop, apparently) by a Perl script snippet to
generate NUL bytes.
Sadly, it does not seem to work on NonStop, as t5562 reportedly hangs.
Worse, this also hangs in the Ubuntu 16.04 agents of the CI builds on
Azure Pipelines: for some reason, the Perl script snippet that is run
via `generate_zero_bytes` in t5562's 'CONTENT_LENGTH overflow ssite_t'
test case tries to write out an infinite amount of NUL bytes unless a
broken pipe is encountered, that snippet never encounters the broken
pipe, and keeps going until the build times out.
Oddly enough, this does not reproduce on the Windows and macOS agents,
nor in a local Ubuntu 18.04.
This developer tried for a day to figure out the exact circumstances
under which this hang happens, to no avail, the details remain a
mystery.
In the end, though, what counts is that this here change incidentally
fixes that hang (maybe also on NonStop?). Even more positively, it gets
rid of yet another unnecessary Perl invocation.
Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
Max Kirillov [Fri, 15 Feb 2019 16:42:37 +0000 (18:42 +0200)]
t5562: do not depend on /dev/zero
It was reported [1] that NonStop platform does not have /dev/zero.
The test uses /dev/zero as a dummy input. Passing case (http-backed
failed because of too big input size) should not be reading anything
from it. If http-backend would erroneously try to read any data
returning EOF probably would be even safer than providing some
meaningless data.
Replace /dev/zero with /dev/null to avoid issues with platforms which do
not have /dev/zero.
Junio C Hamano [Tue, 19 Feb 2019 18:18:15 +0000 (10:18 -0800)]
Revert "t5562: replace /dev/zero with a pipe from generate_zero_bytes"
Revert cc95bc20 ("t5562: replace /dev/zero with a pipe from
generate_zero_bytes", 2019-02-09), as not feeding anything to the
command is a better way to test it.
l10n: de.po: consistent translation of 'root commit'
'root commit' is usually translated as 'Root-Commit'. But in one
occasion it‘s translated as 'Basis-Commit' which is the translation
for 'base commit'.
Ben Peart [Fri, 15 Feb 2019 17:59:21 +0000 (12:59 -0500)]
read-cache: add post-index-change hook
Add a post-index-change hook that is invoked after the index is written in
do_write_locked_index().
This hook is meant primarily for notification, and cannot affect
the outcome of git commands that trigger the index write.
The hook is passed a flag to indicate whether the working directory was
updated or not and a flag indicating if a skip-worktree bit could have
changed. These flags enable the hook to optimize its response to the
index change notification.
Signed-off-by: Ben Peart <redacted> Signed-off-by: Junio C Hamano <redacted>
mingw: safe-guard a bit more against getenv() problems
Running up to v2.21.0, we fixed two bugs that were made prominent by the
Windows-specific change to retain copies of only the 30 latest getenv()
calls' returned strings, invalidating any copies of previous getenv()
calls' return values.
While this really shines a light onto bugs of the form where we hold
onto getenv()'s return values without copying them, it is also a real
problem for users.
And even if Jeff King's patches merged via 773e408881 (Merge branch
'jk/save-getenv-result', 2019-01-29) provide further work on that front,
we are far from done. Just one example: on Windows, we unset environment
variables when spawning new processes, which potentially invalidates
strings that were previously obtained via getenv(), and therefore we
have to duplicate environment values that are somehow involved in
spawning new processes (e.g. GIT_MAN_VIEWER in show_man_page()).
We do not have a chance to investigate, let address, all of those issues
in time for v2.21.0, so let's at least help Windows users by increasing
the number of getenv() calls' return values that are kept valid. The
number 64 was determined by looking at the average number of getenv()
calls per process in the entire test suite run on Windows (which is
around 40) and then adding a bit for good measure. And it is a power of
two (which would have hit yesterday's theme perfectly).
Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
Denton Liu [Fri, 15 Feb 2019 09:26:41 +0000 (01:26 -0800)]
submodule: document default behavior
submodule's default behavior wasn't documented in both git-submodule.txt
and in the usage text of git-submodule. Document the default behavior
similar to how git-remote does it.
Signed-off-by: Denton Liu <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Thu, 14 Feb 2019 05:51:03 +0000 (00:51 -0500)]
ref-filter: drop unused "sz" parameters
Many of our grab_* functions, which parse the object content, take a
buf/sz pair of the object bytes. However, the functions which actually
parse the buffers (like find_wholine() and find_subpos()) never look at
"sz", and instead use functions like strchr() and strchrnul() that
assume the result is NUL-terminated.
This is OK in practice (and common for Git's parsing code), since we
always allocate an extra NUL when loading an object into memory (and
likewise, we are OK with stopping parsing if a commit or tag contains an
embedded NUL).
Let's drop these extra "sz" parameters, as they are misleading about how
the functions intend to access the buffer. We can drop from both the
functions mentioned above, which in turn lets us drop from their
callers, cascading all the way up to the top-level grab_values().
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Thu, 14 Feb 2019 05:50:58 +0000 (00:50 -0500)]
ref-filter: drop unused "obj" parameters
The grab_person() and grab_sub_body_contents() functions take both an
object struct and a buf/sz pair of the object bytes. However, they use
only the latter, since "struct object" does not contain the parsed ident
(nor the whole commit message, of course).
Let's get rid of these misleading "struct object" parameters. It's
possible we may want them in the future (e.g., to generate error
messages that mention the object id), but since these are static
functions, we can easily add them back in later (and if we do want that
information, it's likely we'd pass it through a more generalized
"parsing context" struct anyway).
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Thu, 14 Feb 2019 05:50:54 +0000 (00:50 -0500)]
ref-filter: drop unused buf/sz pairs
The grab_tag_values() and grab_commit_values() functions take both the
"struct object" as well as the buf/sz pair for the actual object bytes.
However, neither function uses the latter, as they pull the data
directly from the parsed object struct.
Let's get rid of these misleading parameters.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Thu, 14 Feb 2019 05:50:46 +0000 (00:50 -0500)]
files-backend: drop refs parameter from split_symref_update()
This parameter was added in fcc42ea0c9 (split_symref_update(): add a
files_ref_store argument, 2016-09-04) without comment, but never used.
The splitting is purely mechanical, and doesn't depend on the particular
ref-store. Let's drop this parameter in the name of simplicity.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Thu, 14 Feb 2019 05:50:32 +0000 (00:50 -0500)]
pack-objects: drop unused parameter from oe_map_new_pack()
Since 43fa44fa3b (pack-objects: move in_pack out of struct object_entry,
2018-04-14), we store the source pack for each object as a small index
rather than as a pointer. When we see a new pack that has no allocated
index, we fall back to generating an array of pointers by calling
oe_map_new_pack().
Perhaps counter-intuitively, that function does not need to actually see
our new index-less pack. It only allocates and populates the array with
the existing packs, after which oe_set_in_pack() actually adds the new
pack to the array.
Let's drop the unused "struct packed_git" argument to oe_map_new_pack()
to avoid confusion.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Thu, 14 Feb 2019 05:50:02 +0000 (00:50 -0500)]
merge-recursive: drop several unused parameters
There are a few functions related to directory renames that have unused
parameters. After consulting with the author in [1], these seem to be
leftover cruft from the development process, and not signs of any bug.
Let's drop them.
git.99rst.org / git.git / log