kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Denton Liu	4f3c1dc5d6	Makefile: respect $(V) in %.cocci.patch target When the %.cocci.patch target was defined in `63f0a758a0` (add coccicheck make target, 2016-09-15), it included a mechanism to suppress the noisy output, similar to the $(QUIET_<x>) family of variables. In the case where one wants to inspect the output hidden by $(QUIET_<x>), one could define $(V) for verbose output. In the %.cocci.patch target, this was not implemented. Move the output suppression into the $(QUIET_SPATCH) variable which is used like the other $(QUIET_<x>) variables. While we're at it, change the number of spaces printed from 5 to 4, like the other variables there. Signed-off-by: Denton Liu <liu.denton@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	46689317ac	ci: also build and test with MS Visual Studio on Azure Pipelines ... because we can, now. Technically, we actually build using `MSBuild`, which is however pretty close to building interactively in Visual Studio. As there is no convenient way to run Git's test suite in Visual Studio, we unpack a Portable Git to run it, using the just-added test helper to allow running test scripts in parallel. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	97fff61012	Move git_sort(), a stable sort, into into libgit.a The `qsort()` function is not guaranteed to be stable, i.e. it does not promise to maintain the order of items it is told to consider equal. In contrast, the `git_sort()` function we carry in `compat/qsort.c` _is_ stable, by virtue of implementing a merge sort algorithm. In preparation for using a stable sort in Git's rename detection, move the stable sort into `libgit.a` so that it is compiled in unconditionally, and rename it to `git_stable_qsort()`. Note: this also makes the hack obsolete that was introduced in `fe21c6b285` (mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8), 2018-10-30), where we included `compat/qsort.c` directly in `compat/mingw.c` to use the stable sort. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	b503a2d515	Makefile: emulate compile in $(HCO) target better Currently, when testing headers using `make hdr-check`, headers are directly compiled. Although this seems to test the headers, this is too strict since we treat the headers as C sources. As a result, this will cause warnings to appear that would otherwise not, such as a static variable definition intended for later use throwing a unused variable warning. In addition, on platforms that can run `make hdr-check` but require custom flags, this target was failing because none of them were being passed to the compiler. For example, on MacOS, the NO_OPENSSL flag was being set but it was not being passed into compiler so the check was failing. Fix these problems by emulating the compile process better, including test compiling dummy .hcc C sources generated from the .h files and passing $(ALL_CFLAGS) into the compiler for the $(HCO) target so that these custom flags can be used. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	9027af58e2	Makefile: run coccicheck on more source files Before, when running the "coccicheck" target, only the source files which were being compiled would have been checked by Coccinelle. However, just because we aren't compiling a source file doesn't mean we have to exclude it from analysis. This will allow us to catch more mistakes, in particular ones that affect Windows-only sources since Coccinelle currently runs only on Linux. Make the "coccicheck" target run on all C sources except for those that are taken from some third-party source. We don't want to patch these files since we want them to be as close to upstream as possible so that it'll be easier to pull in upstream updates. When running a build on Arch Linux with no additional flags provided, after applying this patch, the following sources are now checked: * block-sha1/sha1.c * compat/access.c * compat/basename.c * compat/fileno.c * compat/gmtime.c * compat/hstrerror.c * compat/memmem.c * compat/mingw.c * compat/mkdir.c * compat/mkdtemp.c * compat/mmap.c * compat/msvc.c * compat/pread.c * compat/precompose_utf8.c * compat/qsort.c * compat/setenv.c * compat/sha1-chunked.c * compat/snprintf.c * compat/stat.c * compat/strcasestr.c * compat/strdup.c * compat/strtoimax.c * compat/strtoumax.c * compat/unsetenv.c * compat/win32/dirent.c * compat/win32/path-utils.c * compat/win32/pthread.c * compat/win32/syslog.c * compat/win32/trace2_win32_process_info.c * compat/win32mmap.c * compat/winansi.c * ppc/sha1.c This also results in the following source now being excluded: * compat/obstack.c Instead of generating $(FOUND_C_SOURCES) from a `$(shell $(FIND_SOURCE_FILES))` invocation, an alternative design was considered which involved converting $(FIND_SOURCE_FILES) into $(SOURCE_FILES) which would hold a list of filenames from the $(FIND_SOURCE_FILES) invocation. We would simply filter `%.c` files into $(ALL_C_SOURCES). $(SOURCE_FILES) would then be passed directly to the etags, ctags and cscope commands. We can see from the following invocation $ git ls-files '.[hcS]' '.sh' ':![tp][0-9][0-9][0-9][0-9]' ':!contrib' \| wc -c 12779 that the number of characters in this list would pose a problem on platforms with short command-line length limits (such as CMD which has a max of 8191 characters). As a result, we don't perform this change. However, we can see that the same issue may apply when running Coccinelle since $(COCCI_SOURCES) is also a list of filenames: if ! echo $(COCCI_SOURCES) \| xargs $$limit \ $(SPATCH) --sp-file $< $(SPATCH_FLAGS) \ >$@+ 2>$@.log; \ This is justified since platforms that support Coccinelle generally have reasonably long command-line length limits and so we are safe for the foreseeable future. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	43f8c890fd	Makefile: strip leading ./ in $(FIND_SOURCE_FILES) Currently, $(FIND_SOURCE_FILES) has two modes: if `git ls-files` is present, it will use that to enumerate the files in the repository; else it will use `$(FIND) .` to enumerate the files in the directory. There is a subtle difference between these two methods, however. With ls-files, filenames don't have a leading `./` while with $(FIND), they do. This does not currently pose a problem but in a future patch, we will be using `filter-out` to process the list of files with the assumption that there is no prefix. Unify the two possible invocations in $(FIND_SOURCE_FILES) by using sed to remove the `./` prefix in the $(FIND) case. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	5dedf7de53	Makefile: define THIRD_PARTY_SOURCES Some files in our codebase are borrowed from other projects, and minimally updated to suit our own needs. We'd sometimes need to tell our own sources and these third-party sources apart for management purposes (e.g. we may want to be less strict about coding style and other issues on third-party files). Define the $(MAKE) variable THIRD_PARTY_SOURCES that can be used to match names of third-party sources. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
SZEDER Gábor	2bb74b53a4	Test the progress display 'progress.c' has seen a few fixes recently [1], and, unfortunately, some of those fixes required further fixes [2]. It seems it's time to have a few tests focusing on the subtleties of the progress display. Add the 'test-tool progress' subcommand to help testing the progress display, reading instructions from standard input and turning them into calls to the display_progress() and display_throughput() functions with the given parameters. The progress display is, however, critically dependent on timing, because it's only updated once every second or, if the toal is known in advance, every 1%, and there is the throughput rate as well. These make the progress display far too undeterministic for testing as-is. To address this, add a few testing-specific variables and functions to 'progress.c', allowing the the new test helper to: - Disable the triggered-every-second SIGALRM and set the 'progress_update' flag explicitly based in the input instructions. This way the progress line will be updated deterministically when the test wants it to be updated. - Specify the time elapsed since start_progress() to make the throughput rate calculations deterministic. Add the new test script 't0500-progress-display.sh' to check a few simple cases with and without throughput, and that a shorter progress line properly covers up the previously displayed line in different situations. [1] See commits `545dc345eb` (progress: break too long progress bar lines, 2019-04-12) and `9f1fd84e15` (progress: clear previous progress update dynamically, 2019-04-12). [2] `1aed1a5f25` (progress: avoid empty line when breaking the progress line, 2019-05-19) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Denton Liu	cf6a2d2557	Makefile: strip leading ./ in $(LIB_H) Currently, $(LIB_H) is generated from two modes: if `git ls-files` is present, it will use that to enumerate the files in the repository; else it will use `$(FIND) .` to enumerate the files in the directory. There is a subtle difference between these two methods, however. With ls-files, filenames don't have a leading `./` while with $(FIND), they do. This results in $(CHK_HDRS) having to substitute out the leading `./` before it uses $(LIB_H). Unify the two possible values in $(LIB_H) by using patsubst to remove the `./` prefix at its definition. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Carlo Marcelo Arenas Belón	8991da6a38	grep: make sure NO_LIBPCRE1_JIT disable JIT in PCRE1 `e87de7cab4` ("grep: un-break building with PCRE < 8.32", 2017-05-25) added a restriction for JIT support that is no longer needed after pcre_jit_exec() calls were removed. Reorganize the definitions in grep.h so that JIT support could be detected early and NO_LIBPCRE1_JIT could be used reliably to enforce JIT doesn't get used. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Derrick Stolee	7211b9e753	repo-settings: consolidate some config settings There are a few important config settings that are not loaded during git_default_config. These are instead loaded on-demand. Centralize these config options to a single scan, and store all of the values in a repo_settings struct. The values for each setting are initialized as negative to indicate "unset". This centralization will be particularly important in a later change to introduce "meta" config settings that change the defaults for these config settings. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	5efed0ecf9	rebase: fold git-rebase--common into the -p backend The only remaining scripted part of `git rebase` is the `--preserve-merges` backend. Meaning: there is little reason to keep the "library of common rebase functions" as a separate file. While moving the functions to `git-rebase--preserve-merges.sh`, we also drop the `move_to_original_branch` function that is no longer used. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	d5b581f228	Drop unused git-rebase--am.sh Since `21853626ea` (built-in rebase: call `git am` directly, 2019-01-18), the built-in rebase already uses the built-in `git am` directly. Now that `d03ebd411c` (rebase: remove the rebase.useBuiltin setting, 2019-03-18) even removed the scripted rebase, there is no longer any user of `git-rebase--am.sh`, so let's just remove it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	3a94cb31d5	bin-wrappers: append `.exe` to target paths if necessary When compiling with Visual Studio, the projects' names are identical to the executables modulo the extensions. Read: there will exist both a directory called `git` as well as an executable called `git.exe` in the end. Which means that the bin-wrappers need to target the `.exe` files lest they try to execute directories. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Daniel Ferreira	150791adbf	dir-iterator: add tests for dir-iterator API Create t/helper/test-dir-iterator.c, which prints relevant information about a directory tree iterated over with dir-iterator. Create t/t0066-dir-iterator.sh, which tests that dir-iterator does iterate through a whole directory tree as expected. Signed-off-by: Daniel Ferreira <bnmvco@gmail.com> [matheus.bernardino: update to use test-tool and some minor aesthetics] Helped-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Christian Couder	db27dca5cf	Remove fetch-object.{c,h} in favor of promisor-remote.{c,h} As fetch_objects() is now used only in promisor-remote.c and should't be used outside it, let's move it into promisor-remote.c, make it static there, and remove fetch-object.{c,h}. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Christian Couder	48de315817	Add initial support for many promisor remotes The promisor-remote.{c,h} files will contain functions to manage many promisor remotes. We expect that there will not be a lot of promisor remotes, so it is ok to use a simple linked list to manage them. Helped-by: Jeff King <peff@peff.net> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff Hostetler	dce7d29551	msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Ævar Arnfjörð Bjarmason	b4f207f339	env--helper: new undocumented builtin wrapping git_env_() We have many GIT_TEST_ variables that accept a <boolean> because they're implemented in C, and then some that take <non-empty?> because they're implemented at least partially in shellscript. Add a helper that wraps git_env_bool() and git_env_ulong() as the first step in fixing this. This isn't being added as a test-tool mode because some of these are used outside the test suite. Part of what this tool does can be done via a trick with "git config" added in `83d842dc8c` ("tests: turn on network daemon tests by default", 2014-02-10) for test_tristate(), i.e.: git -c magic.variable="$1" config --bool magic.variable 2>/dev/null But as subsequent changes will show being able to pass along the default value makes all the difference, and we'll be able to replace test_tristate() itself with that. The --type=bool option will be used by subsequent patches, but not --type=ulong. I figured it was easy enough to add it & test for it so I left it in so we'd have wrappers for both git_env_*() functions, and to have a template to make it obvious how we'd add --type=int etc. if it's needed in the future. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff Hostetler	c444bf8cb6	msvc: update Makefile to allow for spaces in the compiler path It is quite common that MS Visual C++ is installed into a location whose path contains spaces, therefore we need to quote it. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Christian Couder	11510decd0	t/helper: add test-oidmap.c This new helper is very similar to "test-hashmap.c" and will help test how `struct oidmap` from oidmap.{c,h} can be used. Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Ævar Arnfjörð Bjarmason	0f50c8e32c	Makefile: remove the NO_R_TO_GCC_LINKER flag Change our default CC_LD_DYNPATH invocation to something GCC likes these days. Since the GCC 4.6 release unknown flags haven't been passed through to ld(1). Thus our previous default of CC_LD_DYNPATH=-R would cause an error on modern GCC unless NO_R_TO_GCC_LINKER was set. This CC_LD_DYNPATH flag is really obscure, and I don't expect anyone except those working on git development ever use this. It's not needed to simply link to libraries like say libpcre, but only for those cases where we're linking to such a library not present in the OS's library directories. See e.g. ldconfig(8) on Linux for more details. I use this to compile my git with a LIBPCREDIR=$HOME/g/pcre2/inst as I'm building that from source, but someone maintaining an OS package is almost certainly not going to use this. They're just going to set USE_LIBPCRE=YesPlease after installing the libpcre dependency, which'll point to OS libraries which ld(1) will find without the help of CC_LD_DYNPATH. Another thing that helps mitigate any potential breakage is that we detect the right type of invocation in configure.ac, which e.g. HP/UX uses[1], as does IBM's AIX package[2]. From what I can tell both AIX and Solaris packagers are building git with GCC, so I'm not adding a corresponding config.mak.uname default to cater to their OS-native linkers. Now for an overview of past development in this area: Our use of "-R" dates back to `455a7f3275` ("More portability.", 2005-09-30). Soon after that in `bbfc63dd78` ("gcc does not necessarily pass runtime libpath with -R", 2006-12-27) the NO_R_TO_GCC flag was added, allowing optional use of "-Wl,-rpath=". Then in `f5b904db6b` ("Makefile: Allow CC_LD_DYNPATH to be overriden", 2008-08-16) the ability to override this flag to something else entirely was added, as some linkers use neither "-Wl,-rpath," nor "-R". From what I can tell we should, with the benefit of hindsight, have made this change back in 2006. GCC & ld supported this type of invocation back then, or since at least binutils-gdb.git's[3] a1ad915dc4 ("[...]Add support for -rpath[...]", 1994-07-20). Further reading and prior art can be found at [4][5][6][7]. Making a plain "-R" an error seems from reading those reports to have been introduced in GCC 4.6 released on March 25, 2011[8], but I couldn't confirm this with absolute certainty, its release notes are ambiguous on the subject, and I couldn't be bothered to try to build & bisect it against GCC 4.5. 1. https://public-inbox.org/git/20190516093412.14795-1-avarab@gmail.com/ 2. https://www.ibm.com/developerworks/aix/library/aix-toolbox/alpha.html 3. git://sourceware.org/git/binutils-gdb.git 4. https://github.com/tsuna/boost.m4/issues/15 5. https://bugzilla.gnome.org/show_bug.cgi?id=641416 6. https://stackoverflow.com/questions/12629042/g-4-6-real-error-unrecognized-option-r 7. https://curl.haxx.se/mail/archive-2014-11/0005.html 8. https://gcc.gnu.org/gcc-4.6/changes.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	082ef75b7b	rebase: fold git-rebase--common into the -p backend The only remaining scripted part of `git rebase` is the `--preserve-merges` backend. Meaning: there is little reason to keep the "library of common rebase functions" as a separate file. While moving the functions to `git-rebase--preserve-merges.sh`, we also drop the `move_to_original_branch` function that is no longer used. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	311c00aae8	Drop unused git-rebase--am.sh Since `21853626ea` (built-in rebase: call `git am` directly, 2019-01-18), the built-in rebase already uses the built-in `git am` directly. Now that `d03ebd411c` (rebase: remove the rebase.useBuiltin setting, 2019-03-18) even removed the scripted rebase, there is no longer any user of `git-rebase--am.sh`, so let's just remove it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	bcb4edf7af	coccicheck: make batch size of 0 mean "unlimited" If you have the memory to handle it, the ideal case is to run a single spatch invocation with all of the source files. But the only way to do so now is to pick an arbitrarily large batch size. Let's make "0" do this, which is a little friendlier (and doesn't otherwise have a useful meaning). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Nguyễn Thái Ngọc Duy	46e91b663b	checkout: split part of it to new command 'restore' Previously the switching branch business of 'git checkout' becomes a new command 'switch'. This adds the restore command for the checking out paths path. Similar to git-switch, a new man page is added to describe what the command will become. The implementation will be updated shortly to match the man page. A couple main differences from 'git checkout <paths>': - 'restore' by default will only update worktree. This matters more when --source is specified ('checkout <tree> <paths>' updates both worktree and index). - 'restore --staged' can be used to restore the index. This command overlaps with 'git reset <paths>'. - both worktree and index could also be restored at the same time (from a tree) when both --staged and --worktree are specified. This overlaps with 'git checkout <tree> <paths>' - default source for restoring worktree and index is the index and HEAD respectively. A different (tree) source could be specified as with --source (). - when both index and worktree are restored, --source must be specified since the default source for these two individual targets are different () - --no-overlay is enabled by default, if an entry is missing in the source, restoring means deleting the entry () I originally went with --from instead of --source. I still think --from is a better name. The short option -f however is already taken by force. And I do think short option is good to have, e.g. to write -s@ or -s@^ instead of --source=HEAD. (**) If you sit down and think about it, moving worktree's source from the index to HEAD makes sense, but nobody is really thinking it through when they type the commands. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	960154b9c1	coccicheck: optionally batch spatch invocations In our "make coccicheck" rule, we currently feed each source file to its own individual invocation of spatch. This has a few downsides: - it repeats any overhead spatch has for starting up and reading the patch file - any included header files may get processed from multiple invocations. This is slow (we see the same header files multiple times) and may produce a resulting patch with repeated hunks (which cannot be applied without further cleanup) Ideally we'd just invoke a single instance of spatch per rule-file and feed it all source files. But spatch can be rather memory hungry when run in this way. I measured the peak RSS going from ~90MB for a single file to ~1900MB for all files. Multiplied by multiple rule files being processed at the same time (for "make -j"), this can make things slower or even cause them to fail (e.g., this is reported to happen on our Travis builds). Instead, let's provide a tunable knob. We'll leave the default at "1", but it can be cranked up to "999" for maximum CPU/memory tradeoff, or people can find points in between that serve their particular machines. Here are a few numbers running a single rule via: SIZES='1 4 16 999' RULE=contrib/coccinelle/object_id.cocci for i in $SIZES; do make clean /usr/bin/time -o $i.out --format='%e \| %U \| %S \| %M' \ make $RULE.patch SPATCH_BATCH_SIZE=$i done for i in $SIZES; do printf '%4d \| %s\n' $i "$(cat $i.out)" done which yields: 1 \| 97.73 \| 93.38 \| 4.33 \| 100128 4 \| 52.80 \| 51.14 \| 1.69 \| 135204 16 \| 35.82 \| 35.09 \| 0.76 \| 284124 999 \| 23.30 \| 23.13 \| 0.20 \| 1903852 The implementation is done with xargs, which should be widely available; it's in POSIX, we rely on it already in the test suite. And "coccicheck" is really a developer-only tool anyway, so it's not a big deal if obscure systems can't run it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Clément Chigot	400caafb2b	git-compat-util: work around for access(X_OK) under root 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: Clément Chigot <clement.chigot@atos.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Junio C Hamano	604a64641d	Makefile: dedup list of files obtained from ls-files 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: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Phillip Wood	0609b741a4	rebase -i: combine rebase--interactive.c with rebase.c 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: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	b7ce24d095	Turn `git serve` into a test helper The `git serve` built-in was introduced in `ed10cb952d` (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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	31cf4a6ba9	check-docs: do not bother checking for legacy scripts' documentation 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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	faa7a096d8	docs: exclude documentation for commands that have been excluded 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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	7c3bd713b1	check-docs: allow command-list.txt to contain excluded commands 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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	724d63569f	help -a: do not list commands that are excluded from the build 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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	0b64e21cc2	Makefile: drop the NO_INSTALL variable 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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff Hostetler	bce9db6de9	trace2: use system/global config for default trace2 settings 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: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	5afb2ce4cd	remote-testgit: move it into the support directory for t5801 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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Nguyễn Thái Ngọc Duy	d787d311db	checkout: split part of it to new command 'switch' "git checkout" doing too many things is a source of confusion for many users (and it even bites old timers sometimes). To remedy that, the command will be split into two new ones: switch and restore. The good old "git checkout" command is still here and will be until all (or most of users) are sick of it. See the new man page for the final design of switch. The actual implementation though is still pretty much the same as "git checkout" and not completely aligned with the man page. Following patches will adjust their behavior to match the man page. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	5ee4246339	check-docs: fix for setups where executables have an extension On Windows, for example, executables (must) have the extension `.exe`. Our `check-docs` target was not prepared for that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	8e6d69591a	check-docs: do not expect guide pages to correspond to commands 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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	057ccba593	check-docs: really look at the documented commands again 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 `5fafce0b78` (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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Ævar Arnfjörð Bjarmason	d03ebd411c	rebase: remove the rebase.useBuiltin setting 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 `7e097e27d3` ("legacy-rebase: backport -C<n> and --whitespace=<option> checks", 2018-11-20) and `9aea5e9286` ("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. `55071ea248` ("rebase: start implementing it as a builtin", 2018-08-07) 2. `d8d0a546f0` ("rebase doc: document rebase.useBuiltin", 2018-11-14) 3. `62c23938fa` ("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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	07a20f569b	Makefile: fix unaligned loads in sha1dc with UBSan 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	90a462725e	stash: optionally use the scripted version again 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: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Paul-Sebastian Ungureanu	40af146834	stash: convert `stash--helper.c` into `stash.c` 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: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Joel Teichroeb	8a0fc8d19d	stash: convert apply to builtin 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: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Ramsay Jones	f23aa18e7f	Makefile: fix 'hdr-check' when GCRYPT not installed 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: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	92b88eba9f	Makefile: use `git ls-files` to list header files, if possible In `d85b0dff72` (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 `ebb7baf02f` (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 `335339758c` (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: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Ævar Arnfjörð Bjarmason	6d5d4b4e93	Makefile: allow for combining DEVELOPER=1 and CFLAGS="..." 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.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago

1 2 3 4 5 ...

2514 Commits (ae821ffe8327ebb24b16ba5a42c6d675050319d7)