summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2020-02-25Merge branch 'bw/remote-rename-update-config'Libravatar Junio C Hamano1-0/+1
"git remote rename X Y" needs to adjust configuration variables (e.g. branch.<name>.remote) whose value used to be X to Y. branch.<name>.pushRemote is now also updated. * bw/remote-rename-update-config: remote rename/remove: gently handle remote.pushDefault config config: provide access to the current line number remote rename/remove: handle branch.<name>.pushRemote config values remote: clean-up config callback remote: clean-up by returning early to avoid one indentation pull --rebase/remote rename: document and honor single-letter abbreviations rebase types
2020-02-10pull --rebase/remote rename: document and honor single-letter abbreviations ↵Libravatar Bert Wesarg1-0/+1
rebase types When 46af44b07d (pull --rebase=<type>: allow single-letter abbreviations for the type, 2018-08-04) landed in Git, it had the side effect that not only 'pull --rebase=<type>' accepted the single-letter abbreviations but also the 'pull.rebase' and 'branch.<name>.rebase' configurations. However, 'git remote rename' did not honor these single-letter abbreviations when reading the 'branch.*.rebase' configurations. We now document the single-letter abbreviations and both code places share a common function to parse the values of 'git pull --rebase=*', 'pull.rebase', and 'branches.*.rebase'. The only functional change is the handling of the `branch_info::rebase` value. Before it was an unsigned enum, thus the truth value could be checked with `branch_info::rebase != 0`. But `enum rebase_type` is signed, thus the truth value must now be checked with `branch_info::rebase >= REBASE_TRUE` Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-30Merge branch 'jk/asan-build-fix'Libravatar Junio C Hamano1-0/+3
Work around test breakages caused by custom regex engine used in libasan, when address sanitizer is used with more recent versions of gcc and clang. * jk/asan-build-fix: Makefile: use compat regex with SANITIZE=address
2020-01-16Makefile: use compat regex with SANITIZE=addressLibravatar Jeff King1-0/+3
Recent versions of the gcc and clang Address Sanitizer produce test failures related to regexec(). This triggers with gcc-10 and clang-8 (but not gcc-9 nor clang-7). Running: make CC=gcc-10 SANITIZE=address test results in failures in t4018, t3206, and t4062. The cause seems to be that when built with ASan, we use a different version of regexec() than normal. And this version doesn't understand the REG_STARTEND flag. Here's my evidence supporting that. The failure in t4062 is an ASan warning: expecting success of 4062.2 '-G matches': git diff --name-only -G "^(0{64}){64}$" HEAD^ >out && test 4096-zeroes.txt = "$(cat out)" ================================================================= ==672994==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fa76f672000 at pc 0x7fa7726f75b6 bp 0x7ffe41bdda70 sp 0x7ffe41bdd220 READ of size 4097 at 0x7fa76f672000 thread T0 #0 0x7fa7726f75b5 (/lib/x86_64-linux-gnu/libasan.so.6+0x4f5b5) #1 0x562ae0c9c40e in regexec_buf /home/peff/compile/git/git-compat-util.h:1117 #2 0x562ae0c9c40e in diff_grep /home/peff/compile/git/diffcore-pickaxe.c:52 #3 0x562ae0c9cc28 in pickaxe_match /home/peff/compile/git/diffcore-pickaxe.c:166 [...] In this case we're looking in a buffer which was mmap'd via reuse_worktree_file(), and whose size is 4096 bytes. But libasan's regex tries to look at byte 4097 anyway! If we tweak Git like this: diff --git a/diff.c b/diff.c index 8e2914c031..cfae60c120 100644 --- a/diff.c +++ b/diff.c @@ -3880,7 +3880,7 @@ static int reuse_worktree_file(struct index_state *istate, */ if (ce_uptodate(ce) || (!lstat(name, &st) && !ie_match_stat(istate, ce, &st, 0))) - return 1; + return 0; return 0; } to use a regular buffer (with a trailing NUL) instead of an mmap, then the complaint goes away. The other failures are actually diff output with an incorrect funcname header. If I instrument xdiff to show the funcname matching like so: diff --git a/xdiff-interface.c b/xdiff-interface.c index 8509f9ea22..f6c3dc1986 100644 --- a/xdiff-interface.c +++ b/xdiff-interface.c @@ -197,6 +197,7 @@ struct ff_regs { struct ff_reg { regex_t re; int negate; + char *printable; } *array; }; @@ -218,7 +219,12 @@ static long ff_regexp(const char *line, long len, for (i = 0; i < regs->nr; i++) { struct ff_reg *reg = regs->array + i; - if (!regexec_buf(&reg->re, line, len, 2, pmatch, 0)) { + int ret = regexec_buf(&reg->re, line, len, 2, pmatch, 0); + warning("regexec %s:\n regex: %s\n buf: %.*s", + ret == 0 ? "matched" : "did not match", + reg->printable, + (int)len, line); + if (!ret) { if (reg->negate) return -1; break; @@ -264,6 +270,7 @@ void xdiff_set_find_func(xdemitconf_t *xecfg, const char *value, int cflags) expression = value; if (regcomp(&reg->re, expression, cflags)) die("Invalid regexp to look for hunk header: %s", expression); + reg->printable = xstrdup(expression); free(buffer); value = ep + 1; } then when compiling with ASan and gcc-10, running the diff from t4018.66 produces this: $ git diff -U1 cpp-skip-access-specifiers warning: regexec did not match: regex: ^[ ]*[A-Za-z_][A-Za-z_0-9]*:[[:space:]]*($|/[/*]) buf: private: warning: regexec matched: regex: ^((::[[:space:]]*)?[A-Za-z_].*)$ buf: private: diff --git a/cpp-skip-access-specifiers b/cpp-skip-access-specifiers index 4d4a9db..ebd6f42 100644 --- a/cpp-skip-access-specifiers +++ b/cpp-skip-access-specifiers @@ -6,3 +6,3 @@ private: void DoSomething(); int ChangeMe; }; void DoSomething(); - int ChangeMe; + int IWasChanged; }; That first regex should match (and is negated, so it should be telling us _not_ to match "private:"). But it wouldn't if regexec() is looking at the whole buffer, and not just the length-limited line we've fed to regexec_buf(). So this is consistent again with REG_STARTEND being ignored. The correct output (compiling without ASan, or gcc-9 with Asan) looks like this: warning: regexec matched: regex: ^[ ]*[A-Za-z_][A-Za-z_0-9]*:[[:space:]]*($|/[/*]) buf: private: [...more lines that we end up not using...] warning: regexec matched: regex: ^((::[[:space:]]*)?[A-Za-z_].*)$ buf: class RIGHT : public Baseclass diff --git a/cpp-skip-access-specifiers b/cpp-skip-access-specifiers index 4d4a9db..ebd6f42 100644 --- a/cpp-skip-access-specifiers +++ b/cpp-skip-access-specifiers @@ -6,3 +6,3 @@ class RIGHT : public Baseclass void DoSomething(); - int ChangeMe; + int IWasChanged; }; So it really does seem like libasan's regex engine is ignoring REG_STARTEND. We should be able to work around it by compiling with NO_REGEX, which would use our local regexec(). But to make matters even more interesting, this isn't enough by itself. Because ASan has support from the compiler, it doesn't seem to intercept our call to regexec() at the dynamic library level. It actually recognizes when we are compiling a call to regexec() and replaces it with ASan-specific code at that point. And unlike most of our other compat code, where we might have git_mmap() or similar, the actual symbol name in the compiled compat/regex code is regexec(). So just compiling with NO_REGEX isn't enough; we still end up in libasan! We can work around that by having the preprocessor replace regexec with git_regexec (both in the callers and in the actual implementation), and we truly end up with a call to our custom regex code, even when compiling with ASan. That's probably a good thing to do anyway, as it means anybody looking at the symbols later (e.g., in a debugger) would have a better indication of which function is which. So we'll do the same for the other common regex functions (even though just regexec() is enough to fix this ASan problem). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15t: directly test parse_pathspec_file()Libravatar Alexandr Miloslavskiy1-0/+1
Previously, `parse_pathspec_file()` was tested indirectly by invoking git commands with properly crafted inputs. As demonstrated by the previous bugfix, testing complicated black boxes indirectly can lead to tests that silently test the wrong thing. Introduce direct tests for `parse_pathspec_file()`. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-25Merge branch 'js/add-p-in-c'Libravatar Junio C Hamano1-0/+1
The effort to move "git-add--interactive" to C continues. * js/add-p-in-c: built-in add -p: show helpful hint when nothing can be staged built-in add -p: only show the applicable parts of the help text built-in add -p: implement the 'q' ("quit") command built-in add -p: implement the '/' ("search regex") command built-in add -p: implement the 'g' ("goto") command built-in add -p: implement hunk editing strbuf: add a helper function to call the editor "on an strbuf" built-in add -p: coalesce hunks after splitting them built-in add -p: implement the hunk splitting feature built-in add -p: show different prompts for mode changes and deletions built-in app -p: allow selecting a mode change as a "hunk" built-in add -p: handle deleted empty files built-in add -p: support multi-file diffs built-in add -p: offer a helpful error message when hunk navigation failed built-in add -p: color the prompt and the help text built-in add -p: adjust hunk headers as needed built-in add -p: show colored hunks by default built-in add -i: wire up the new C code for the `patch` command built-in add -i: start implementing the `patch` functionality in C
2019-12-25Merge branch 'jc/drop-gen-hdrs'Libravatar Junio C Hamano1-3/+2
Code cleanup. * jc/drop-gen-hdrs: Makefile: drop GEN_HDRS
2019-12-25Merge branch 'ds/sparse-cone'Libravatar Junio C Hamano1-0/+1
Management of sparsely checked-out working tree has gained a dedicated "sparse-checkout" command. * ds/sparse-cone: (21 commits) sparse-checkout: improve OS ls compatibility sparse-checkout: respect core.ignoreCase in cone mode sparse-checkout: check for dirty status sparse-checkout: update working directory in-process for 'init' sparse-checkout: cone mode should not interact with .gitignore sparse-checkout: write using lockfile sparse-checkout: use in-process update for disable subcommand sparse-checkout: update working directory in-process sparse-checkout: sanitize for nested folders unpack-trees: add progress to clear_ce_flags() unpack-trees: hash less in cone mode sparse-checkout: init and set in cone mode sparse-checkout: use hashmaps for cone patterns sparse-checkout: add 'cone' mode trace2: add region in clear_ce_flags sparse-checkout: create 'disable' subcommand sparse-checkout: add '--stdin' option to set subcommand sparse-checkout: 'set' subcommand clone: add --sparse mode sparse-checkout: create 'init' subcommand ...
2019-12-16fix-typo: consecutive-word duplicationsLibravatar ryenus1-1/+1
Correct unintentional duplication(s) of words, such as "the the", and "can can" etc. The changes are only applied to cases where it's fixing what is clearly wrong or prone to misunderstanding, as suggested by the reviewers. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Denton Liu <liu.denton@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: ryenus <ryenus@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13Makefile: drop GEN_HDRSLibravatar Junio C Hamano1-3/+2
When ebb7baf0 ("Makefile: add a hdr-check target", 2018-09-19) implemented hdr-check target, it wanted to leave some header files exempt from the stricter check the target implements, and added GEN_HDRS macro. This however is probably a bad move for two reasons: - If we value the header cleanliness check, we eventually want to teach our header generating scripts to produce clean headers. Keeping the blanket "generated headers can be left as dirty as we want" exception does not nudge us in the right direction. - There is a list of generated header files, GENERATED_H, which is used to keep track of dependencies. Presence of GEN_HDRS that is too similarly named would confuse developers who are adding new generated header files which list to add theirs. - Even though unicode-width.h could be generated using a contrib/ script, as far as our build infrastructure is concerned, it is a source file that is tracked in the source control system. Its presence in GEN_HDRS list is doubly misleading. Get rid of GEN_HDRS, which is used only once to list the headers we do not run hdr-check test on, and instead explicitly list that the ones, either tracked or generated, that we exempt from the test. This allows GENERATED_H to be the sole "here are build artifact header files that are expendable" list, so use it in the clean target to $(RM) them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13built-in add -i: start implementing the `patch` functionality in CLibravatar Johannes Schindelin1-0/+1
In the previous steps, we re-implemented the main loop of `git add -i` in C, and most of the commands. Notably, we left out the actual functionality of `patch`, as the relevant code makes up more than half of `git-add--interactive.perl`, and is actually pretty independent of the rest of the commands. With this commit, we start to tackle that `patch` part. For better separation of concerns, we keep the code in a separate file, `add-patch.c`. The new code is still guarded behind the `add.interactive.useBuiltin` config setting, and for the moment, it can only be called via `git add -p`. The actual functionality follows the original implementation of 5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely (for example, we use string offsets rather than copying strings around, and after seeing whether the `k` and `j` commands are applicable, in the C version we remember which previous/next hunk was undecided, and use it rather than looking again when the user asked to jump). As a further deviation from that commit, We also use a comma instead of a slash to separate the available commands in the prompt, as the current version of the Perl script does this, and we also add a line about the question mark ("print help") to the help text. While it is tempting to use this conversion of `git add -p` as an excuse to work on `apply_all_patches()` so that it does _not_ want to read a file from `stdin` or from a file, but accepts, say, an `strbuf` instead, we will refrain from this particular rabbit hole at this stage. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-05Merge branch 'js/builtin-add-i'Libravatar Junio C Hamano1-0/+1
The beginning of rewriting "git add -i" in C. * js/builtin-add-i: built-in add -i: implement the `help` command built-in add -i: use color in the main loop built-in add -i: support `?` (prompt help) built-in add -i: show unique prefixes of the commands built-in add -i: implement the main loop built-in add -i: color the header in the `status` command built-in add -i: implement the `status` command diff: export diffstat interface Start to implement a built-in version of `git add --interactive`
2019-11-22sparse-checkout: create builtin with 'list' subcommandLibravatar Derrick Stolee1-0/+1
The sparse-checkout feature is mostly hidden to users, as its only documentation is supplementary information in the docs for 'git read-tree'. In addition, users need to know how to edit the .git/info/sparse-checkout file with the right patterns, then run the appropriate 'git read-tree -mu HEAD' command. Keeping the working directory in sync with the sparse-checkout file requires care. Begin an effort to make the sparse-checkout feature a porcelain feature by creating a new 'git sparse-checkout' builtin. This builtin will be the preferred mechanism for manipulating the sparse-checkout file and syncing the working directory. The documentation provided is adapted from the "git read-tree" documentation with a few edits for clarity in the new context. Extra sections are added to hint toward a future change to a more restricted pattern set. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-14Start to implement a built-in version of `git add --interactive`Libravatar Johannes Schindelin1-0/+1
Unlike previous conversions to C, where we started with a built-in helper, we start this conversion by adding an interception in the `run_add_interactive()` function when the new opt-in `add.interactive.useBuiltin` config knob is turned on (or the corresponding environment variable `GIT_TEST_ADD_I_USE_BUILTIN`), and calling the new internal API function `run_add_i()` that is implemented directly in libgit.a. At this point, the built-in version of `git add -i` only states that it cannot do anything yet. In subsequent patches/patch series, the `run_add_i()` function will gain more and more functionality, until it is feature complete. The whole arc of the conversion can be found in the PRs #170-175 at https://github.com/gitgitgadget/git. The "--helper approach" can unfortunately not be used here: on Windows we face the very specific problem that a `system()` call in Perl seems to close `stdin` in the parent process when the spawned process consumes even one character from `stdin`. Which prevents us from implementing the main loop in C and still trying to hand off to the Perl script. The very real downside of the approach we have to take here is that the test suite won't pass with `GIT_TEST_ADD_I_USE_BUILTIN=true` until the conversion is complete (the `--helper` approach would have let it pass, even at each of the incremental conversion steps). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13test-tool: use 'read-graph' helperLibravatar Derrick Stolee1-0/+1
The 'git commit-graph read' subcommand is used in test scripts to check that the commit-graph contents match the expected data. Mostly, this helps check the header information and the list of chunks. Users do not need this information, so move the functionality to a test helper. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18Merge branch 'dl/allow-running-cocci-verbosely'Libravatar Junio C Hamano1-1/+2
Dev support update. * dl/allow-running-cocci-verbosely: Makefile: respect $(V) in %.cocci.patch target
2019-10-15Merge branch 'js/azure-pipelines-msvc'Libravatar Junio C Hamano1-0/+4
CI updates. * js/azure-pipelines-msvc: ci: also build and test with MS Visual Studio on Azure Pipelines ci: really use shallow clones on Azure Pipelines tests: let --immediate and --write-junit-xml play well together test-tool run-command: learn to run (parts of) the testsuite vcxproj: include more generated files vcxproj: only copy `git-remote-http.exe` once it was built msvc: work around a bug in GetEnvironmentVariable() msvc: handle DEVELOPER=1 msvc: ignore some libraries when linking compat/win32/path-utils.h: add #include guards winansi: use FLEX_ARRAY to avoid compiler warning msvc: avoid using minus operator on unsigned types push: do not pretend to return `int` from `die_push_simple()`
2019-10-12Makefile: respect $(V) in %.cocci.patch targetLibravatar Denton Liu1-1/+2
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>
2019-10-11Merge branch 'cb/pcre1-cleanup'Libravatar Junio C Hamano1-7/+2
PCRE fixes. * cb/pcre1-cleanup: grep: refactor and simplify PCRE1 support grep: make sure NO_LIBPCRE1_JIT disable JIT in PCRE1
2019-10-09Merge branch 'js/diff-rename-force-stable-sort'Libravatar Junio C Hamano1-1/+1
The rename detection logic sorts a list of rename source candidates by similarity to pick the best candidate, which means that a tie between sources with the same similarity is broken by the original location in the original candidate list (which is sorted by path). Force the sorting by similarity done with a stable sort, which is not promised by system supplied qsort(3), to ensure consistent results across platforms. * js/diff-rename-force-stable-sort: diffcore_rename(): use a stable sort Move git_sort(), a stable sort, into into libgit.a
2019-10-07Merge branch 'dl/honor-cflags-in-hdr-check'Libravatar Junio C Hamano1-3/+9
Dev support. * dl/honor-cflags-in-hdr-check: ci: run `hdr-check` as part of the `Static Analysis` job Makefile: emulate compile in $(HCO) target better pack-bitmap.h: remove magic number promisor-remote.h: include missing header apply.h: include missing header
2019-10-07Merge branch 'sg/progress-fix'Libravatar Junio C Hamano1-0/+1
Regression fix for progress output. * sg/progress-fix: Test the progress display Revert "progress: use term_clear_line()"
2019-10-07Merge branch 'dl/cocci-everywhere'Libravatar Junio C Hamano1-9/+21
Coccinelle checks are done on more source files than before now. * dl/cocci-everywhere: Makefile: run coccicheck on more source files Makefile: strip leading ./ in $(FIND_SOURCE_FILES) Makefile: define THIRD_PARTY_SOURCES Makefile: strip leading ./ in $(LIB_H)
2019-10-06ci: also build and test with MS Visual Studio on Azure PipelinesLibravatar Johannes Schindelin1-0/+4
... 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>
2019-10-02Move git_sort(), a stable sort, into into libgit.aLibravatar Johannes Schindelin1-1/+1
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 fe21c6b285d (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>
2019-09-28Makefile: emulate compile in $(HCO) target betterLibravatar Denton Liu1-3/+9
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>
2019-09-18Merge branch 'cc/multi-promisor'Libravatar Junio C Hamano1-1/+1
Teach the lazy clone machinery that there can be more than one promisor remote and consult them in order when downloading missing objects on demand. * cc/multi-promisor: Move core_partial_clone_filter_default to promisor-remote.c Move repository_format_partial_clone to promisor-remote.c Remove fetch-object.{c,h} in favor of promisor-remote.{c,h} remote: add promisor and partial clone config to the doc partial-clone: add multiple remotes in the doc t0410: test fetching from many promisor remotes builtin/fetch: remove unique promisor remote limitation promisor-remote: parse remote.*.partialclonefilter Use promisor_remote_get_direct() and has_promisor_remote() promisor-remote: use repository_format_partial_clone promisor-remote: add promisor_remote_reinit() promisor-remote: implement promisor_remote_get_direct() Add initial support for many promisor remotes fetch-object: make functions return an error code t0410: remove pipes after git commands
2019-09-17Makefile: run coccicheck on more source filesLibravatar Denton Liu1-6/+2
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>
2019-09-17Makefile: strip leading ./ in $(FIND_SOURCE_FILES)Libravatar Denton Liu1-0/+1
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>
2019-09-17Makefile: define THIRD_PARTY_SOURCESLibravatar Denton Liu1-0/+15
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>
2019-09-17Test the progress displayLibravatar SZEDER Gábor1-0/+1
'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>
2019-09-17Makefile: strip leading ./ in $(LIB_H)Libravatar Denton Liu1-3/+3
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>
2019-09-09Merge branch 'ds/feature-macros'Libravatar Junio C Hamano1-0/+1
A mechanism to affect the default setting for a (related) group of configuration variables is introduced. * ds/feature-macros: repo-settings: create feature.experimental setting repo-settings: create feature.manyFiles setting repo-settings: parse core.untrackedCache commit-graph: turn on commit-graph by default t6501: use 'git gc' in quiet mode repo-settings: consolidate some config settings
2019-08-26grep: make sure NO_LIBPCRE1_JIT disable JIT in PCRE1Libravatar Carlo Marcelo Arenas Belón1-7/+2
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>
2019-08-13repo-settings: consolidate some config settingsLibravatar Derrick Stolee1-0/+1
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>
2019-08-02Merge branch 'js/visual-studio'Libravatar Junio C Hamano1-1/+1
Support building Git with Visual Studio The bits about .git/branches/* have been dropped from the series. We may want to drop the support for it, but until that happens, the tests should rely on the existence of the support to pass. * js/visual-studio: (23 commits) git: avoid calling aliased builtins via their dashed form bin-wrappers: append `.exe` to target paths if necessary .gitignore: ignore Visual Studio's temporary/generated files .gitignore: touch up the entries regarding Visual Studio vcxproj: also link-or-copy builtins msvc: add a Makefile target to pre-generate the Visual Studio solution contrib/buildsystems: add a backend for modern Visual Studio versions contrib/buildsystems: handle options starting with a slash contrib/buildsystems: also handle -lexpat contrib/buildsystems: handle libiconv, too contrib/buildsystems: handle the curl library option contrib/buildsystems: error out on unknown option contrib/buildsystems: optionally capture the dry-run in a file contrib/buildsystems: redirect errors of the dry run into a log file contrib/buildsystems: ignore gettext stuff contrib/buildsystems: handle quoted spaces in filenames contrib/buildsystems: fix misleading error message contrib/buildsystems: ignore irrelevant files in Generators/ contrib/buildsystems: ignore invalidcontinue.obj Vcproj.pm: urlencode '<' and '>' when generating VC projects ...
2019-07-29bin-wrappers: append `.exe` to target paths if necessaryLibravatar Johannes Schindelin1-1/+1
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>
2019-07-25Merge branch 'mt/dir-iterator-updates'Libravatar Junio C Hamano1-0/+1
Adjust the dir-iterator API and apply it to the local clone optimization codepath. * mt/dir-iterator-updates: clone: replace strcmp by fspathcmp clone: use dir-iterator to avoid explicit dir traversal clone: extract function from copy_or_link_directory clone: copy hidden paths at local clone dir-iterator: add flags parameter to dir_iterator_begin dir-iterator: refactor state machine model dir-iterator: use warning_errno when possible dir-iterator: add tests for dir-iterator API clone: better handle symlinked files at .git/objects/ clone: test for our behavior on odd objects/* content
2019-07-25Merge branch 'ab/test-env'Libravatar Junio C Hamano1-0/+1
Many GIT_TEST_* environment variables control various aspects of how our tests are run, but a few followed "non-empty is true, empty or unset is false" while others followed the usual "there are a few ways to spell true, like yes, on, etc., and also ways to spell false, like no, off, etc." convention. * ab/test-env: env--helper: mark a file-local symbol as static tests: make GIT_TEST_FAIL_PREREQS a boolean tests: replace test_tristate with "git env--helper" tests README: re-flow a previously changed paragraph tests: make GIT_TEST_GETTEXT_POISON a boolean t6040 test: stop using global "script" variable config.c: refactor die_bad_number() to not call gettext() early env--helper: new undocumented builtin wrapping git_env_*() config tests: simplify include cycle test
2019-07-19Merge branch 'cc/test-oidmap'Libravatar Junio C Hamano1-0/+1
Extend the test coverage a bit. * cc/test-oidmap: t0016: add 'remove' subcommand test test-oidmap: remove 'add' subcommand test-hashmap: remove 'hash' command oidmap: use sha1hash() instead of static hash() function t: add t0016-oidmap.sh t/helper: add test-oidmap.c
2019-07-11dir-iterator: add tests for dir-iterator APILibravatar Daniel Ferreira1-0/+1
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>
2019-07-09Merge branch 'jh/msvc'Libravatar Junio C Hamano1-1/+41
Support to build with MSVC has been updated. * jh/msvc: msvc: ignore .dll and incremental compile output msvc: avoid debug assertion windows in Debug Mode msvc: do not pretend to support all signals msvc: add pragmas for common warnings msvc: add a compile-time flag to allow detailed heap debugging msvc: support building Git using MS Visual C++ msvc: update Makefile to allow for spaces in the compiler path msvc: fix detect_msys_tty() msvc: define ftello() msvc: do not re-declare the timespec struct msvc: mark a variable as non-const msvc: define O_ACCMODE msvc: include sigset_t definition msvc: fix dependencies of compat/msvc.c mingw: replace mingw_startup() hack obstack: fix compiler warning cache-tree/blame: avoid reusing the DEBUG constant t0001 (mingw): do not expect a specific order of stdout/stderr Mark .bat files as requiring CR/LF endings mingw: fix a typo in the msysGit-specific section
2019-07-09Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-0/+2
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-06-25Remove fetch-object.{c,h} in favor of promisor-remote.{c,h}Libravatar Christian Couder1-1/+0
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>
2019-06-25Add initial support for many promisor remotesLibravatar Christian Couder1-0/+1
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>
2019-06-25msvc: support building Git using MS Visual C++Libravatar Jeff Hostetler1-0/+40
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>
2019-06-21env--helper: new undocumented builtin wrapping git_env_*()Libravatar Ævar Arnfjörð Bjarmason1-0/+1
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>
2019-06-20msvc: update Makefile to allow for spaces in the compiler pathLibravatar Jeff Hostetler1-1/+1
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>
2019-06-17t/helper: add test-oidmap.cLibravatar Christian Couder1-0/+1
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>
2019-06-13Merge branch 'ab/deprecate-R-for-dynpath'Libravatar Junio C Hamano1-14/+1
The way of specifying the path to find dynamic libraries at runtime has been simplified. The old default to pass -R/path/to/dir has been replaced with the new default to pass -Wl,-rpath,/path/to/dir, which is the more recent GCC uses. Those who need to build with an old GCC can still use "CC_LD_DYNPATH=-R" * ab/deprecate-R-for-dynpath: Makefile: remove the NO_R_TO_GCC_LINKER flag
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 11:21:58 +0000