aboutsummaryrefslogtreecommitdiffstats
path: root/diff-lib.c
diff options
context:
space:
mode:
Diffstat (limited to 'diff-lib.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-19 20:30:13 +0000
supports empty arrays with NULL pointers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-29add QSORTRené Scharfe2-0/+27 Add the macro QSORT, a convenient wrapper for qsort(3) that infers the size of the array elements and supports the convention of initializing empty arrays with a NULL pointer, which we use in some places. Calling qsort(3) directly with a NULL pointer is undefined -- even with an element count of zero -- and allows the compiler to optimize away any following NULL checks. Using the macro avoids such surprises. Add a semantic patch as well to demonstrate the macro's usage and to automate the transformation of trivial cases. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-26Fifth batch for 2.11Junio C Hamano1-0/+66 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-22introduce CHECKOUT_INITRené Scharfe5-9/+5 Add a static initializer for struct checkout and use it throughout the code base. It's shorter, avoids a memset(3) call and makes sure the base_dir member is initialized to a valid (empty) string. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-22docs/cvs-migration: mention cvsimport caveatsJeff King1-0/+4 Back when this guide was written, cvsimport was the only game in town. These days it is probably not the best option. Rather than go into details, let's point people to the note at the top of cvsimport which gives other options. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-22docs/cvs-migration: update link to cvsps homepageJeff King1-1/+1 The old page gives a 404 now. Searching for "cvsps" via Google returns a GitHub project page as the top hit. Reported-by: Dan Pritts Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-22docs/cvsimport: prefer cvs-fast-export to parsecvsJeff King1-1/+1 parsecvs maintenance was taken over by ESR, and the name changed to cvs-fast-export as it learned to support that output format. Let's point to cvs-fast-export, as it should have additional bug-fixes and be more convenient to use. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-22clone: pass --progress decision to recursive submodulesJeff King3-5/+34 When cloning with "--recursive", we'd generally expect submodules to show progress reports if the main clone did, too. In older versions of git, this mostly worked out of the box. Since we show progress by default when stderr is a tty, and since the child clones inherit the parent stderr, then both processes would come to the same decision by default. If the parent clone was asked for "--quiet", we passed down "--quiet" to the child. However, if stderr was not a tty and the user specified "--progress", we did not propagate this to the child. That's a minor bug, but things got much worse when we switched recently to submodule--helper's update_clone command. With that change, the stderr of the child clones are always connected to a pipe, and we never output progress at all. This patch teaches git-submodule and git-submodule--helper how to pass down an explicit "--progress" flag when cloning. The clone command then decides to propagate that flag based on the cloning decision made earlier (which takes into account isatty(2) of the parent process, existing --progress or --quiet flags, etc). Since the child processes always run without a tty on stderr, we don't have to worry about passing an explicit "--no-progress"; it's the default for them. This fixes the recent loss of progress during recursive clones. And as a bonus, it makes: git clone --recursive --progress ... 2>&1 | cat work by triggering progress explicitly in the children. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-22travis-ci: ask homebrew for its path instead of hardcoding itLars Schneider1-1/+1 The TravisCI macOS build is broken because homebrew (a macOS dependency manager) changed its internal directory structure [1]. This is a problem because we modify the Perforce dependencies in the homebrew repository before installing them. Fix it by asking homebrew for its path instead of hardcoding it. [1] https://github.com/Homebrew/brew/commit/0a09ae30f8b6117ad699b4a0439010738989c547 Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-21Fourth batch for 2.11Junio C Hamano1-15/+86 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-21t3700-add: do not check working tree file mode without POSIXPERMJohannes Sixt1-4/+2 A recently introduced test checks the result of 'git status' after setting the executable bit on a file. This check does not yield the expected result when the filesystem does not support the executable bit. What we care about is that a file added with "--chmod=+x" has executable bit in the index and that "--chmod=+x" (or any other options for that matter) does not muck with working tree files. The former is tested by other existing tests, so let's check the latter more explicitly and only under POSIXPERM prerequisite. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-21regex: use regexec_buf()Johannes Schindelin5-33/+17 The new regexec_buf() function operates on buffers with an explicitly specified length, rather than NUL-terminated strings. We need to use this function whenever the buffer we want to pass to regexec(3) may have been mmap(2)ed (and is hence not NUL-terminated). Note: the original motivation for this patch was to fix a bug where `git diff -G <regex>` would crash. This patch converts more callers, though, some of which allocated to construct NUL-terminated strings, or worse, modified buffers to temporarily insert NULs while calling regexec(3). By converting them to use regexec_buf(), the code has become much cleaner. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-09-21regex: add regexec_buf() that can work on a non NUL-terminated stringJohannes Schindelin2-1/+15 We just introduced a test that demonstrates that our sloppy use of regexec() on a mmap()ed area can result in incorrect results or even hard crashes. So what we need to fix this is a function that calls regexec() on a length-delimited, rather than a NUL-terminated, string. Happily, there is an extension to regexec() introduced by the NetBSD project and present in all major regex implementation including Linux', MacOSX' and the one Git includes in compat/regex/: by using the (non-POSIX) REG_STARTEND flag, it is possible to tell the regexec() function that it should only look at the offsets between pmatch[0].rm_so and pmatch[0].rm_eo. That is exactly what we need. Since support for REG_STARTEND is so widespread by now, let's just introduce a helper function that always uses it, and tell people on a platform whose regex library does not support it to use the one from our compat/regex/ directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>