- 25 4月, 2019 1 次提交
-
-
由 Clément Chigot 提交于
On AIX, access(X_OK) may succeed when run as root even if the execution isn't possible. This behavior is allowed by POSIX which says: ... for a process with appropriate privileges, an implementation may indicate success for X_OK even if execute permission is not granted to any user. It can lead hook programs to have their execution refused: git commit -m content fatal: cannot exec '.git/hooks/pre-commit': Permission denied Add NEED_ACCESS_ROOT_HANDLER in order to use an access helper function. It checks with stat if any executable flags is set when the current user is root. Signed-off-by: NClément Chigot <clement.chigot@atos.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 4月, 2019 1 次提交
-
-
由 Junio C Hamano 提交于
Since 33533975 ("Makefile: ask "ls-files" to list source files if available", 2011-10-18), we optionally asked "ls-files" to list the source files that ought to exist, as a faster approximation for "find" on working tree files. This works reasonably well, except that it ends up listing the same path multiple times if the index is unmerged. Because the original use of this construct was to name files to run etags over, and the etags command happily takes the same filename multiple times without causing any harm, there was no problem (other than perhaps spending slightly more cycles, but who cares how fast the TAGS file gets updated). We however recently added a similar call to "ls-files" to list *.h files, instead of using "find", in 92b88eba ("Makefile: use `git ls-files` to list header files, if possible", 2019-03-04). In this new use of "ls-files", the resulting list $(LIB_H) is used for, among other things, generating the header files to run hdr-check target, and the duplicate unfortunately becomes a true problem. It causes $(MAKE) to notice that there are multiple %.hco targets and complain. Let the resulting list consumed by $(sort), which deduplicates, to fix this. Helped-by: NEric Sunshine <sunshine@sunshineco.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 4月, 2019 7 次提交
-
-
由 Phillip Wood 提交于
In order to run `rebase -i` without forking `rebase--interactive` it will be convenient to have all the code from rebase--interactive.c in rebase.c. This is a straight forward copy of the code from rebase--interactive.c, it will be simplified slightly in the next commit. Signed-off-by: NPhillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
The `git serve` built-in was introduced in ed10cb95 (serve: introduce git-serve, 2018-03-15) as a backend to serve Git protocol v2, probably originally intended to be spawned by `git upload-pack`. However, in the version that the protocol v2 patches made it into core Git, `git upload-pack` calls the `serve()` function directly instead of spawning `git serve`; The only reason in life for `git serve` to survive as a built-in command is to provide a way to test the protocol v2 functionality. Meaning that it does not even have to be a built-in that is installed with end-user facing Git installations, but it can be a test helper instead. Let's make it so. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
In the recent years, there has been a big push to convert more and more of Git's commands that are implemented as scripts to built-ins written in pure, portable C, for robustness, speed and portability. One strategy that served us well is to convert those scripts incrementally, starting by renaming the scripts to `git-legacy-<command>`, then introducing a built-in that does nothing else at first than checking the config setting `<command>.useBuiltin` (which defaults to `false` at the outset) and handing off to the legacy script if so asked. Obviously, those `git-legacy-<command>` commands share the documentation with the built-in `git-<command>`, and are not intended to be called directly anyway. So let's not try to ensure that they are documented separately from their built-in versions. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
When building with certain build options, some commands are excluded from the build. For example, `git-credential-cache` is skipped when building with `NO_UNIX_SOCKETS`. Let's not build or package documentation for those excluded commands. This issue was pointed out rightfully when running `make check-docs` on Windows, where we do not yet have Unix sockets, and therefore the `credential-cache` command is excluded (yet its documentation was built and shipped). Note: building the documentation via `make -C Documentation` leaves the build system with no way to determine which commands have been excluded. If called thusly, we gracefully fail to exclude their documentation. Only when building the documentation via the top-level Makefile will it get excluded properly, or after building `Documentation/GIT-EXCLUDED-PROGRAMS` manually. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
Among other things, the `check-docs` target ensures that `command-list.txt` no longer contains commands that were dropped (or that were never added in the first place). To do so, it compares the list of commands from that file to the commands listed in `$(ALL_COMMANDS)`. However, some build options exclude commands from the latter. Fix the target to handle this situation correctly by taking the just-introduced `$(EXCLUDED_PROGRAMS)` into account. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
When built with NO_CURL or with NO_UNIX_SOCKETS, some commands are skipped from the build. It does not make sense to list them in the output of `git help -a`, so let's just not. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
The last user was just removed; There is no longer any need to carry it around. Should we ever run into a need for it again, it is easy enough to revert this commit. It is unlikely, though, that we need `NO_INSTALL` again: as we saw with the just-removed item, `git-remote-testgit`, we have better locations to put executables and scripts that we do not want to install, e.g. a subdirectory in `t/`, or `contrib/`. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 4月, 2019 1 次提交
-
-
由 Jeff Hostetler 提交于
Teach git to read the system and global config files for default Trace2 settings. This allows system-wide Trace2 settings to be installed and inherited to make it easier to manage a collection of systems. The original GIT_TR2* environment variables are loaded afterwards and can be used to override the system settings. Only the system and global config files are used. Repo and worktree local config files are ignored. Likewise, the "-c" command line arguments are also ignored. These limits are for performance reasons. (1) For users not using Trace2, there should be minimal overhead to detect that Trace2 is not enabled. In particular, Trace2 should not allocate lots of otherwise unused data strucutres. (2) For accurate performance measurements, Trace2 should be initialized as early in the git process as possible, and before most of the normal git process initialization (which involves discovering the .git directory and reading a hierarchy of config files). Signed-off-by: NJeff Hostetler <jeffhost@microsoft.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 4月, 2019 1 次提交
-
-
由 Johannes Schindelin 提交于
The `git-remote-testgit` script is really only used in `t5801-remote-helpers.sh`. It does not even contain any `@@<MAGIC>@@` placeholders that would need to be interpolated via `make git-remote-testgit`. Let's just move it to a new home, decluttering the top-level directory and clarifying that this is just a test helper, not an official Git command that we would want to ever support. Suggested by Ævar Arnfjörð Bjarmason. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 4月, 2019 3 次提交
-
-
由 Johannes Schindelin 提交于
On Windows, for example, executables (must) have the extension `.exe`. Our `check-docs` target was not prepared for that. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
When we want to see what commands are listed in `command-list.txt` but not installed, we currently include lines that refer to guides, e.g. `gitattributes` or `gitcli`. Let's not include those lines, as they are not referring to commands. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
As part of the `check-docs` target, we verify that commands that are documented are actually in the current list of commands to be built. However, this logic broke in 5fafce0b (check-docs: get documented command list from Makefile, 2012-08-08), when we tried to make the logic safer by not looking at the files in the worktree, but at the list of files to be generated in `Documentation/Makefile`. While this was the right thing to do, it failed to accommodate for the fact that `make -C Documentation/ print-man1`, unlike `ls Documentation/*.txt`, would *not* print lines starting with the prefix `Documentation/`. At long last, let's fix this. Note: This went undetected due to a funny side effect of the `ALL_PROGRAMS` variable starting with a space. That space, together with the extra space we inserted before `$(ALL_PROGRAMS)` in the case " $(ALL_PROGRAMS)" in *" $$cmd ") [...] construct, is responsible that this case arm is used when `cmd` is empty (which was clearly not intended to be the case). Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 3月, 2019 1 次提交
-
-
由 Ævar Arnfjörð Bjarmason 提交于
Remove the rebase.useBuiltin setting, which was added as an escape hatch to disable the builtin version of rebase first released with Git 2.20. See [1] for the initial implementation of rebase.useBuiltin, and [2] and [3] for the documentation and corresponding GIT_TEST_REBASE_USE_BUILTIN option. Carrying the legacy version is a maintenance burden as seen in 7e097e27 ("legacy-rebase: backport -C<n> and --whitespace=<option> checks", 2018-11-20) and 9aea5e92 ("rebase: fix regression in rebase.useBuiltin=false test mode", 2019-02-13). Since the built-in version has been shown to be stable enough let's remove the legacy version. As noted in [3] having use_builtin_rebase() shell out to get its config doesn't make any sense anymore, that was done for the purposes of spawning the legacy rebase without having modified any global state. Let's instead handle this case in rebase_config(). There's still a bunch of references to git-legacy-rebase in po/*.po, but those will be dealt with in time by the i18n effort. Even though this configuration variable only existed two releases let's not entirely delete the entry from the docs, but note its absence. Individual versions of git tend to be around for a while due to distro packaging timelines, so e.g. if we're "lucky" a given version like 2.21 might be installed on say OSX for half a decade. That'll mean some people probably setting this in config, and then when they later wonder if it's needed they can Google search the config option name or check it in git-config. It also allows us to refer to the docs from the warning for details. 1. 55071ea2 ("rebase: start implementing it as a builtin", 2018-08-07) 2. d8d0a546 ("rebase doc: document rebase.useBuiltin", 2018-11-14) 3. 62c23938 ("tests: add a special setup where rebase.useBuiltin is off", 2018-11-14) 3. https://public-inbox.org/git/nycvar.QRO.7.76.6.1903141544110.41@tvgsbejvaqbjf.bet/Acked-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 3月, 2019 1 次提交
-
-
由 Jeff King 提交于
The sha1dc library uses unaligned loads on platforms that support them. This is normally what you'd want for performance, but it does cause UBSan to complain when we compile with SANITIZE=undefined. Just like we set -DNO_UNALIGNED_LOADS for our own code in that case, we should set -DSHA1DC_FORCE_ALIGNED_ACCESS. Of course that does nothing without pulling in the patches from sha1dc to respect that define. So let's do that, too, updating both the submodule link and our in-tree copy (from the same commit). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 3月, 2019 3 次提交
-
-
由 Johannes Schindelin 提交于
We recently converted the `git stash` command from Unix shell scripts to builtins. Let's end users a way out when they discover a bug in the builtin command: `stash.useBuiltin`. As the file name `git-stash` is already in use, let's rename the scripted backend to `git-legacy-stash`. To make the test suite pass with `stash.useBuiltin=false`, this commit also backports rudimentary support for `-q` (but only *just* enough to appease the test suite), and adds a super-ugly hack to force exit code 129 for `git stash -h`. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Paul-Sebastian Ungureanu 提交于
The old shell script `git-stash.sh` was removed and replaced entirely by `builtin/stash.c`. In order to do that, `create` and `push` were adapted to work without `stash.sh`. For example, before this commit, `git stash create` called `git stash--helper create --message "$*"`. If it called `git stash--helper create "$@"`, then some of these changes wouldn't have been necessary. This commit also removes the word `helper` since now stash is called directly and not by a shell script. Signed-off-by: NPaul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com> Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Joel Teichroeb 提交于
Add a builtin helper for performing stash commands. Converting all at once proved hard to review, so starting with just apply lets conversion get started without the other commands being finished. The helper is being implemented as a drop in replacement for stash so that when it is complete it can simply be renamed and the shell script deleted. Delete the contents of the apply_stash shell function and replace it with a call to stash--helper apply until pop is also converted. Signed-off-by: NJoel Teichroeb <joel@teichroeb.net> Signed-off-by: NPaul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com> Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 3月, 2019 1 次提交
-
-
由 Ramsay Jones 提交于
If the GCRYPT_SHA256 build variable is not set, then the 'hdr-check' target complains about the missing <gcrypt.h> header file. Add the 'sha256/gcrypt.h' header file to the exception list, if the build variable is not defined. While here, replace the 'xdiff%' filter pattern with 'xdiff/%' (and similarly for the compat pattern) since the original pattern inadvertently excluded the 'xdiff-interface.h' header. Signed-off-by: NRamsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 3月, 2019 1 次提交
-
-
由 Johannes Schindelin 提交于
In d85b0dff (Makefile: use `find` to determine static header dependencies, 2014-08-25), we switched from a static list of header files to a dynamically-generated one, asking `find` to enumerate them. Back in those days, we did not use `$(LIB_H)` by default, and many a `make` implementation seems smart enough not to run that `find` command in that case, so it was deemed okay to run `find` for special targets requiring this macro. However, as of ebb7baf0 (Makefile: add a hdr-check target, 2018-09-19), $(LIB_H) is part of a global rule and therefore must be expanded. Meaning: this `find` command has to be run upon every `make` invocation. In the presence of many a worktree, this can tax the developers' patience quite a bit. Even in the absence of worktrees or other untracked files and directories, the cost of I/O to generate that list of header files is simply a lot larger than a simple `git ls-files` call. Therefore, just like in 33533975 (Makefile: ask "ls-files" to list source files if available, 2011-10-18), we now prefer to use `git ls-files` to enumerate the header files to enumerating them via `find`, falling back to the latter if the former failed (which would be the case e.g. in a worktree that was extracted from a source .tar file rather than from a clone of Git's sources). This has one notable consequence: we no longer include `command-list.h` in `LIB_H`, as it is a generated file, not a tracked one, but that is easily worked around. Of the three sites that use `LIB_H`, two (`LOCALIZED_C` and `CHK_HDRS`) already handle generated headers separately. In the third, the computed-dependency fallback, we can just add in a reference to $(GENERATED_H). Likewise, we no longer include not-yet-tracked header files in `LIB_H`. Given the speed improvements, these consequences seem a comparably small price to pay. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Acked-by: NRamsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 2月, 2019 6 次提交
-
-
由 Ævar Arnfjörð Bjarmason 提交于
Ever since the DEVELOPER=1 facility introduced there's been no way to have custom CFLAGS (e.g. CFLAGS="-O0 -g -ggdb3") while still benefiting from the set of warnings and assertions DEVELOPER=1 enables. This is because the semantics of variables in the Makefile are such that the user setting CFLAGS overrides anything we set, including what we're doing in config.mak.dev[1]. So let's introduce a "DEVELOPER_CFLAGS" variable in config.mak.dev and add it to ALL_CFLAGS. Before this the ALL_CFLAGS variable would (basically, there's some nuance we won't go into) be set to: $(CPPFLAGS) [$(CFLAGS) *or* $(CFLAGS) in config.mak.dev] $(BASIC_CFLAGS) $(EXTRA_CPPFLAGS) But will now be: $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(BASIC_CFLAGS) $(EXTRA_CPPFLAGS) The reason for putting DEVELOPER_CFLAGS first is to allow for selectively overriding something DEVELOPER=1 brings in. On both GCC and Clang later settings override earlier ones. E.g. "-Wextra -Wno-extra" will enable no "extra" warnings, but not if those two arguments are reversed. Examples of things that weren't possible before, but are now: # Use -O0 instead of -O2 for less painful debuggng DEVELOPER=1 CFLAGS="-O0 -g" # DEVELOPER=1 plus -Wextra, but disable some of the warnings DEVELOPER=1 DEVOPTS="no-error extra-all" CFLAGS="-O0 -g -Wno-unused-parameter" The reason for the patches leading up to this one re-arranged the various *FLAGS assignments and includes is just for readability. The Makefile supports assignments out of order, e.g.: $ cat Makefile X = $(A) $(B) $(C) A = A B = B include c.mak all: @echo $(X) $ cat c.mak C=C $ make A B C So we could have gotten away with the much smaller change of changing "CFLAGS" in config.mak.dev to "DEVELOPER_CFLAGS" and adding that to ALL_CFLAGS earlier in the Makefile "before" the config.mak.* includes. But I think it's more readable to use variables "after" they're included. 1. https://www.gnu.org/software/make/manual/html_node/Overriding.htmlSigned-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
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: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Now the only other non-program assignment in the previous list is PTHREAD_CFLAGS, which'll be moved elsewhere in a follow-up change. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
The top of the Makfile is mostly separated into logical steps like set default configuration, set programs etc., but there's some deviation from that. Let's add mostly comments where they're missing, remove those that don't add anything. The whitespace tweaking makes subsequent patches smaller. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
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 4dc00021 ("Makefile: add 'strip' target", 2006-01-12) which added it doesn't provide an explanation. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Remove a comment referring to a caveat that hasn't been applicable since 18b0fc1c ("Git.pm: Kill Git.xs for now", 2006-09-23). At the time of 8d7f586f ("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 18b0fc1c discussed above. Since my 20d2a30f ("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: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2019 2 次提交
-
-
由 Jeff Hostetler 提交于
Create unit tests for Trace2. Signed-off-by: NJeff Hostetler <jeffhost@microsoft.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff Hostetler 提交于
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: NJeff Hostetler <jeffhost@microsoft.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 2月, 2019 1 次提交
-
-
由 Johannes Schindelin 提交于
In cc95bc20 (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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 2月, 2019 1 次提交
-
-
由 Duy Nguyen 提交于
On various BSD's, fileno(fp) is implemented as a macro that directly accesses the fields in the FILE * object, which breaks a function that accepts a "void *fp" parameter and calls fileno(fp) and expect it to work. Work it around by adding a compile-time knob FILENO_IS_A_MACRO that inserts a real helper function in the middle of the callchain. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 2月, 2019 1 次提交
-
-
由 brian m. carlson 提交于
When serializing UTF-16 (and UTF-32), there are three possible ways to write the stream. One can write the data with a BOM in either big-endian or little-endian format, or one can write the data without a BOM in big-endian format. Most systems' iconv implementations choose to write it with a BOM in some endianness, since this is the most foolproof, and it is resistant to misinterpretation on Windows, where UTF-16 and the little-endian serialization are very common. For compatibility with Windows and to avoid accidental misuse there, Git always wants to write UTF-16 with a BOM, and will refuse to read UTF-16 without it. However, musl's iconv implementation writes UTF-16 without a BOM, relying on the user to interpret it as big-endian. This causes t0028 and the related functionality to fail, since Git won't read the file without a BOM. Add a Makefile and #define knob, ICONV_OMITS_BOM, that can be set if the iconv implementation has this behavior. When set, Git will write a BOM manually for UTF-16 and UTF-32 and then force the data to be written in UTF-16BE or UTF-32BE. We choose big-endian behavior here because the tests use the raw "UTF-16" encoding, which will be big-endian when the implementation requires this knob to be set. Update the tests to detect this case and write test data with an added BOM if necessary. Always write the BOM in the tests in big-endian format, since all iconv implementations that omit a BOM must use big-endian serialization according to the Unicode standard. Preserve the existing behavior for systems which do not have this knob enabled, since they may use optimized implementations, including defaulting to the native endianness, which may improve performance. Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 2月, 2019 1 次提交
-
-
由 Ramsay Jones 提交于
In order to enable greater user customisation of the SPARSE_FLAGS variable, we introduce a new SP_EXTRA_FLAGS variable to use for target specific settings. Without using the new variable, setting the SPARSE_FLAGS on the 'make' command-line would also override the value set by the target-specific rules in the Makefile (effectively making them useless). Also, this enables the SP_EXTRA_FLAGS to be used in the future for any other internal customisations, such as for some platform specific values. In addition, we initialise the SPARSE_FLAGS to the default (empty) value using a conditional assignment (?=). This allows SPARSE_FLAGS to be set from the environment as well as from the command-line. Signed-off-by: NRamsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 1月, 2019 3 次提交
-
-
由 Derrick Stolee 提交于
Sometimes there are test failures in the 'pu' branch. This is somewhat expected for a branch that takes the very latest topics under development, and those sometimes have semantic conflicts that only show up during test runs. This also can happen when running the test suite with different GIT_TEST_* environment variables that interact in unexpected ways This causes a problem for the test coverage reports, as the typical 'make coverage-test coverage-report' run halts at the first failed test. If that test is early in the suite, then many valuable tests are not exercising the code and the coverage report becomes noisy with false positives. Add a new 'coverage-prove' target to the Makefile, modeled after the 'coverage-test' target. This compiles the source using the coverage flags, then runs the test suite using the 'prove' tool. Since the coverage machinery is not thread-safe, enforce that the tests are run in sequence by appending '-j1' to GIT_PROVE_OPTS. Signed-off-by: NDerrick Stolee <dstolee@microsoft.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
The fact that Git's test suite is implemented in Unix shell script that is as portable as we can muster, combined with the fact that Unix shell scripting is foreign to Windows (and therefore has to be emulated), results in pretty abysmal speed of the test suite on that platform, for pretty much no other reason than that language choice. For comparison: while the Linux build & test is typically done within about 8 minutes, the Windows build & test typically lasts about 80 minutes in Azure Pipelines. To help with that, let's use the Azure Pipeline feature where you can parallelize jobs, make jobs depend on each other, and pass artifacts between them. The tests are distributed using the following heuristic: listing all test scripts ordered by size in descending order (as a cheap way to estimate the overall run time), every Nth script is run (where N is the total number of parallel jobs), starting at the index corresponding to the parallel job. This slicing is performed by a new function that is added to the `test-tool`. To optimize the overall runtime of the entire Pipeline, we need to move the Windows jobs to the beginning (otherwise there would be a very decent chance for the Pipeline to be run only the Windows build, while all the parallel Windows test jobs wait for this single one). We use Azure Pipelines Artifacts for both the minimal Git for Windows SDK as well as the built executables, as deduplication and caching close to the agents makes that really fast. For comparison: while downloading and unpacking the minimal Git for Windows SDK via PowerShell takes only one minute (down from anywhere between 2.5 to 7 when using a shallow clone), uploading it as Pipeline Artifact takes less than 30s and downloading and unpacking less than 20s (sometimes even as little as only twelve seconds). Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
This will come in handy when publishing the results of Git's test suite during an automated Azure DevOps run. Note: we need to make extra sure that invalid UTF-8 encoding is turned into valid UTF-8 (using the Replacement Character, \uFFFD) because t9902's trace contains such invalid byte sequences, and the task in the Azure Pipeline that uploads the test results would refuse to do anything if it was asked to parse an .xml file with invalid UTF-8 in it. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 1月, 2019 2 次提交
-
-
由 Josh Steadmon 提交于
The comment explaining how to build the fuzzers was broken in 927c77e7 ("Makefile: use FUZZ_CXXFLAGS for linking fuzzers", 2018-11-14). When building fuzzers, all .c files must be compiled with coverage tracing enabled. This is not possible when using only FUZZ_CXXFLAGS, as that flag is only applied to the fuzzers themselves. Switching back to CFLAGS fixes the issue. Signed-off-by: NJosh Steadmon <steadmon@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Josh Steadmon 提交于
Break load_commit_graph_one() into a new function, parse_commit_graph(). The latter function operates on arbitrary buffers, which makes it suitable as a fuzzing target. Since parse_commit_graph() is only called by load_commit_graph_one() (and the fuzzer described below), we omit error messages that would be duplicated by the caller. Adds fuzz-commit-graph.c, which provides a fuzzing entry point compatible with libFuzzer (and possibly other fuzzing engines). Signed-off-by: NJosh Steadmon <steadmon@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 1月, 2019 1 次提交
-
-
由 Elijah Newren 提交于
As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: NElijah Newren <newren@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 11月, 2018 1 次提交
-
-
由 Josh Steadmon 提交于
OSS-Fuzz requires C++-specific flags to link fuzzers. Passing these in CFLAGS causes lots of build warnings. Using separate FUZZ_CXXFLAGS avoids this. Signed-off-by: NJosh Steadmon <steadmon@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-