Re: [PATCH 4/4] config: avoid calling `labs()` on too-large data type

Am 13.06.19 um 13:49 schrieb Johannes Schindelin via GitGitGadget: > From: Johannes Schindelin > > The `labs()` function operates, as the initial `l` suggests, on `long` > parameters. However, in `config.c` we tried to use it on values of type > `intmax_t`. > > This problem was found by GCC v9.x.

Re: [PATCH] completion: do not cache if --git-completion-helper fails

On Fri, Jun 14, 2019 at 1:07 PM Felipe Contreras wrote: > > On Thu, Jun 13, 2019 at 9:53 PM Duy Nguyen wrote: > > > > On Fri, Jun 14, 2019 at 7:30 AM Felipe Contreras > > wrote: > > > > One way or the other, shouldn't my tests be merged? The issue is still > > > there, and it's nice to have test

Re: Can we just get rid of kwset & obstack in favor of optimistically using PCRE v2 JIT?

On Sat, Jun 15 2019, brian m. carlson wrote: > On 2019-06-14 at 22:55:17, Ævar Arnfjörð Bjarmason wrote: >> It seems most packagers build with PCRE v2 now (CC: >> git-packagers@). I.e. we'd keep something like compile_fixed_regexp() >> (and as an aside just use PCRE's \Q...\E instead of our own

Re: Can we just get rid of kwset & obstack in favor of optimistically using PCRE v2 JIT?

On 2019-06-14 at 22:55:17, Ævar Arnfjörð Bjarmason wrote: > It seems most packagers build with PCRE v2 now (CC: > git-packagers@). I.e. we'd keep something like compile_fixed_regexp() > (and as an aside just use PCRE's \Q...\E instead of our own escaping). > > We'd have performance regression for

[PATCH] Use an intermediate file between between git blame and sed to avoid git blame's exit code being hidden.

From: Michael Platings --- t/t8014-blame-ignore-fuzzy.sh | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/t/t8014-blame-ignore-fuzzy.sh b/t/t8014-blame-ignore-fuzzy.sh index 1ff59624e9..13f3313710 100755 --- a/t/t8014-blame-ignore-fuzzy.sh +++ b/t/t8014-blame-ign

[PATCH 2/2] use COPY_ARRAY for copying arrays

Convert calls of memcpy(3) to use COPY_ARRAY, which shortens and simplifies the code a bit. Patch generated by Coccinelle and contrib/coccinelle/array.cocci. Signed-off-by: Rene Scharfe --- fast-import.c | 2 +- kwset.c | 2 +- packfile.c| 6 +++--- pretty.c | 4 ++-- 4 files cha

[PATCH 1/2] coccinelle: use COPY_ARRAY for copying arrays

The current semantic patch for COPY_ARRAY transforms memcpy(3) calls on pointers, but Coccinelle distinguishes them from arrays. It already contains three rules to handle the options for sizeof (i.e. source, destination and type), and handling arrays as source and destination would require four ti

[PATCH] fsmonitor: avoid signed integer overflow / infinite loop

883e248b8a ("fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.", 2017-09-22) uses an int in a loop that would wrap if index_state->cache_nr (unsigned) is bigger than INT_MAX Signed-off-by: Carlo Marcelo Arenas Belón --- fsmonitor.c | 8 +

GOOD MORNING FROM UNITED STATES OF AMERICA

-- Greetings , I seize this opportunity to bring to your notice about an Engineer who is from your country and also bearing the same surname with you, He died three years ago, he work as a contractor here in Lome-Togo, West Africa and left huge amount of money and properties in Union Togolaise de

Re: [PATCH] stash: fix show referencing stash index

On 6/15/19 1:26 PM, Thomas Gummerer wrote: > diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh > index ea30d5f6a0..3973cbda0e 100755 > --- a/t/t3903-stash.sh > +++ b/t/t3903-stash.sh > @@ -708,6 +708,24 @@ test_expect_success 'invalid ref of the form "n", n >= > N' ' > git stash drop > ' >

[PATCH] stash: fix show referencing stash index

On 06/14, Mike Hommey wrote: > Hi, > > `git stash ` where n is a number used to work until 2.21.*. > It doesn't work in 2.22.0. > > Bisection points to: > > dc7bd382b1063303f4f45d243bff371899285acb is the first bad commit > commit dc7bd382b1063303f4f45d243bff371899285acb > Author: Paul-Sebastia

[PATCH v4 4/4] test-hashmap: remove 'hash' command

If hashes like strhash() are updated, for example to use a different hash algorithm, we should not have to be updating t0011 to change out the hashes. As long as hashmap can store and retrieve values, and that it performs well, we should not care what are the values of the hashes. Let's just focus

[PATCH v4 1/4] 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 Helped-by: Jeff King Signed-off-by: Christian Couder --- Makefile | 1 + t/helper/test-oidmap.c | 126 ++

[PATCH v4 0/4] Test oidmap

Unlike hashmap that has t/helper/test-hashmap.c and t/t0011-hashmap.sh oidmap has no specific test. The goal of this small patch series is to change that and also improve oidmap a bit while at it. Changes compared to V3 are the following: - removed "hash" command in test-oidmap.c and "hash" tes

[PATCH v4 3/4] oidmap: use sha1hash() instead of static hash() function

From: Christian Couder Get rid of the static hash() function in oidmap.c which is redundant with sha1hash(). Use sha1hash() directly instead. Let's be more consistent and not use several hash functions doing nearly exactly the same thing. Signed-off-by: Christian Couder --- oidmap.c | 13 +++-

[PATCH v4 2/4] t: add t0016-oidmap.sh

From: Christian Couder Add actual tests for operations using `struct oidmap` from oidmap.{c,h}. Helped-by: SZEDER Gábor Helped-by: Jeff King Signed-off-by: Christian Couder --- t/t0016-oidmap.sh | 84 +++ 1 file changed, 84 insertions(+) create mo

Hello Dear

-- Hello Dear, This is Miss Lina Karim, How are you today hope all is well with you, please I will need your urgent attention regarding this important discussion kindly write me back here : linakari...@gmail.com: for more details, Thanks, Miss Lina Karim

Re: Can we just get rid of kwset & obstack in favor of optimistically using PCRE v2 JIT?

> It seems most packagers build with PCRE v2 now (CC: > git-packagers@). I.e. we'd keep something like compile_fixed_regexp() > (and as an aside just use PCRE's \Q...\E instead of our own escaping). OpenBSD does PCRE v1 without JIT but HardenedBSD does and therefore segfaults when calling: `git gr

Re: rev-parse --is-bare-repository incorrect when work tree is set

On Sat, Jun 15, 2019 at 02:59:50AM +0100, Sam Bazley wrote: > rev-parse --is-bare-repository incorrectly outputs "false" when testing > a bare repository with the work tree set. > > To reproduce: > > $ git init --bare testbare > $ git --git-dir=testbare rev-parse --is-bare-repository > true > $ g

Re: 'git interpret-trailers' is tripped by comment characters other than '#'

On Fri, Jun 14, 2019 at 5:10 PM Jeff King wrote: > > On Fri, Jun 14, 2019 at 08:35:04PM +0900, Masahiro Yamada wrote: > > > Perhaps, 'git interpret-trailers' should be changed > > to recognize core.commentChar ? > > It looks like the trailer code does respect it, but the > interpret-trailers progr

Re: Deadname rewriting

On Sat, Jun 15 2019, Phil Hord wrote: > I know name-scrubbing is already covered in filter-branch and other > places. But we have a scenario becoming more common that makes it a > more sensitive topic. > > At $work we have a long time employee who has changed their name from > Alice to Bob. Bob

Re: Deadname rewriting

On Jun 14 2019, Phil Hord wrote: > It feels like `.git/info/grafts` would work the best if it could be > distributed with the project, but I'm pretty sure that's a non-starter > for many reasons. The graft file is obsoleted by git replace. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG