Re: git archive generates tar with malformed pax extended attribute

Am 29.05.19 um 03:17 schrieb Jeff King: > On Wed, May 29, 2019 at 01:34:32AM +0200, René Scharfe wrote: >> Parsing trees with symlinks twice is not ideal, but keeps the set >> structure simple -- a standard oidset suffices. > > If blobs comes after trees (and they usually do i

Re: git archive generates tar with malformed pax extended attribute

Am 30.05.19 um 13:55 schrieb Jeff King: > On Wed, May 29, 2019 at 07:54:44PM +0200, René Scharfe wrote: > >> Am 29.05.19 um 03:17 schrieb Jeff King: >>> But here the problem is in the tree, not the blob. So we're not finding >>> suspect blobs, but rather re-che

Re: [PATCH 1/2] url: do not read past end of buffer

Am 03.06.19 um 22:45 schrieb Matthew DeVore: > url_decode_internal could have been tricked into reading past the length > of the **query buffer if there are fewer than 2 characters after a % (in > a null-terminated string, % would have to be the last character). > Prevent this from happening by che

Re: [PATCH 2/2] url: do not allow %00 to represent NULL in URLs

Am 03.06.19 um 22:45 schrieb Matthew DeVore: > There is no reason to allow %00 to terminate a string, so do not allow it. > Otherwise, we end up returning arbitrary content in the string (that which is > after the %00) which is effectively hidden from callers and can escape sanity > checks and vali

Re: [PATCH] am: add --check option

Am 03.06.19 um 16:25 schrieb Drew DeVault: > @@ -2195,6 +2206,8 @@ int cmd_am(int argc, const char **argv, const char > *prefix) > 0, PARSE_OPT_NONEG), > OPT_BOOL('c', "scissors", &state.scissors, > N_("strip everything before a scissors li

Re: [PATCH 1/1] diffcore-rename: speed up register_rename_src

Am 08.06.19 um 16:42 schrieb Jeff Hostetler via GitGitGadget: > From: Jeff Hostetler > > Teach register_rename_src() to see if new file pair > can simply be appended to the rename_src[] array before > performing the binary search to find the proper insertion > point. > > This is a performance opti

Re: [PATCH 2/2] archive: avoid spawning `gzip`

Am 01.05.19 um 20:18 schrieb Jeff King: > On Wed, May 01, 2019 at 07:45:05PM +0200, René Scharfe wrote: > >>> But since the performance is still not quite on par with `gzip`, I would >>> actually rather not, and really, just punt on that one, stating that >>

[PATCH] cleanup: fix possible overflow errors in binary search, part 2

Calculating the sum of two array indexes to find the midpoint between them can overflow, i.e. code like this is unsafe for big arrays: mid = (first + last) >> 1; Make sure the intermediate value stays within the boundaries instead, like this: mid = first + ((last - first) >> 1);

Re: [PATCH] cleanup: fix possible overflow errors in binary search, part 2

Am 13.06.19 um 21:42 schrieb Martin Ågren: > On Thu, 13 Jun 2019 at 19:54, René Scharfe wrote: >> >> Calculating the sum of two array indexes to find the midpoint between >> them can overflow, i.e. code like this is unsafe for big arrays: >> >> mid = (fi

[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 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

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 4/4] config: avoid calling `labs()` on too-large data type

Am 16.06.19 um 08:48 schrieb René Scharfe: > 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

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

Am 16.06.19 um 10:24 schrieb René Scharfe: > Am 16.06.19 um 08:48 schrieb René Scharfe: >> Am 13.06.19 um 13:49 schrieb Johannes Schindelin via GitGitGadget: >>> From: Johannes Schindelin >>> >>> The `labs()` function operates, as the initial `l` suggests, o

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

Am 17.06.19 um 00:26 schrieb Junio C Hamano: > René Scharfe writes: > >>>>> To fix it, let's just "unroll" the function (i.e. negate the value if it >>>>> is negative). >>>> >>>> There's also imaxabs(3). > > T

[PATCH v2 1/3] config: use unsigned_mult_overflows to check for overflows

parse_unit_factor() checks if a K, M or G is present after a number and multiplies it by 2^10, 2^20 or 2^30, respectively. One of its callers checks if the result is smaller than the number alone to detect overflows. The other one passes 1 as the number and does multiplication and overflow check

[PATCH v2 2/3] config: don't multiply in parse_unit_factor()

parse_unit_factor() multiplies the number that is passed to it with the value of a recognized unit factor (K, M or G for 2^10, 2^20 and 2^30, respectively). All callers pass in 1 as a number, though, which allows them to check the actual multiplication for overflow before they are doing it themsel

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

Am 21.06.19 um 20:35 schrieb Johannes Schindelin: > Hi René, > > On Thu, 20 Jun 2019, René Scharfe wrote: > >> Subject: [PATCH] config: simplify unit suffix handling >> >> parse_unit_factor() checks if a K, M or G is present after a number and >> multiplies it

[PATCH v2 3/3] config: simplify parsing of unit factors

Just return the value of the factor or zero for unrecognized strings instead of using an output reference and a separate return value to indicate success. This is shorter and simpler. It basically reverts that function to before c8deb5a146 ("Improve error messages when int/long cannot be parsed f

Re: [PATCH 15/17] khash: rename oid helper functions

Am 20.06.19 um 20:27 schrieb Jeff King: > On Thu, Jun 20, 2019 at 10:44:17AM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >>> For use in object_id hash tables, we have oid_hash() and oid_equal(). >>> But these are confusingly similar to the existing oideq() and the >>> oidhash() we plan

Re: [PATCH 2/3] sequencer: factor out todo command name parsing

Am 25.06.19 um 12:11 schrieb Phillip Wood via GitGitGadget: > From: Phillip Wood > > Factor out the code that parses the name of the command at the start of > each line in the todo file into it's own function so that it can be used > in the next commit. "Factor out" sounds like functionality is i

Re: [PATCH 1/1] clean: show an error message when the path is too long

Am 16.07.19 um 16:04 schrieb Johannes Schindelin via GitGitGadget: > From: Johannes Schindelin > > Without an error message when stat() failed, e.g. `git clean` would > abort without an error message, leaving the user quite puzzled. > > In particular on Windows, where the default maximum path leng

Re: [PATCH] archive: Store checksum correctly

Am 23.07.19 um 18:49 schrieb Junio C Hamano: > Matt Turner writes: > >> tar2sqfs (part of https://github.com/topics/tar2sqfs) rejects tarballs >> made with git archive with the message >> >> invalid tar header checksum! >> >> tar2sqfs recomputes the tarball's checksum to verify it. Its checksu

Re: [PATCH] archive: Store checksum correctly

Am 23.07.19 um 21:38 schrieb René Scharfe: > is_checksum_valid() in > https://github.com/AgentD/squashfs-tools-ng/blob/master/lib/tar/checksum.c > compares the formatted checksum byte-by-byte. That seems > unnecessarily strict. Parsing and comparing the numerical value > of the ch

Re: [RFC PATCH v2] grep: allow for run time disabling of JIT in PCRE

Am 29.07.19 um 12:59 schrieb Carlo Marcelo Arenas Belón: > PCRE1 allowed for a compile time flag to disable JIT, but PCRE2 never > had one, forcing the use of JIT if -P was requested. > > After ed0479ce3d (Merge branch 'ab/no-kwset' into next, 2019-07-15) > the PCRE2 engine will be used more broadl

Re: [PATCH 3/3] grep: plug leak of pcre chartables in PCRE2

Am 28.07.19 um 03:41 schrieb Carlo Arenas: > On Sat, Jul 27, 2019 at 4:48 PM Ævar Arnfjörð Bjarmason > wrote: >>> + free((void *)p->pcre_tables); >> >> Is the cast really needed? I'm rusty on the rules, removing it from the >> pcre_free() you might have copied this from produces a warning for

Re: [PATCH 3/3] grep: plug leak of pcre chartables in PCRE2

Am 30.07.19 um 02:08 schrieb Carlo Arenas: > On Mon, Jul 29, 2019 at 1:35 PM René Scharfe wrote: >> >> Am 28.07.19 um 03:41 schrieb Carlo Arenas: >>> On Sat, Jul 27, 2019 at 4:48 PM Ævar Arnfjörð Bjarmason >>> wrote: >>>>> + free((void *)p-&g

Re: [RFC PATCH v2] grep: allow for run time disabling of JIT in PCRE

Am 30.07.19 um 02:49 schrieb Carlo Arenas: > On Mon, Jul 29, 2019 at 10:47 AM Junio C Hamano wrote: >> René Scharfe writes: >>>> +pcre.jit:: >>>> +If set to false, disable JIT when using PCRE. Defaults to >>>> +true. >>>> +i

Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop

Am 31.07.19 um 05:27 schrieb Jeff King: > One thing that makes it all a bit funky is that the "put" lines also > output the old value (which is what all those NULLs) are. And I think > that solves my "value3" puzzlement from earlier. It is not part of the > iteration at all, but rather the result o

Re: Support for --stdin-paths in commit, add, etc

Am 31.07.19 um 17:45 schrieb Alexandr Miloslavskiy: > Our suggestion is to change commands such as 'commit', 'add', etc to > also work with --stdin-paths. If a command already supports stdin for > any purpose, then trying to use both options will return an error. Would it make sense to have a --pa

Re: Simplify-by-decoration with decorate-refs-exclude

sion option --simplify-by-decoration together with the log option --decorate-refs-exclude and having it simplify over the restricted set of refs. Reported-by: Étienne SERVAIS Signed-off-by: René Scharfe --- revision.c | 8 +++- t/t4202-log.sh | 15 +++ 2 files changed, 22 inserti

Re: Simplify-by-decoration with decorate-refs-exclude

Am 02.08.19 um 21:14 schrieb Junio C Hamano: > I can see how this would help, but it somehow feels a bit brittle > to rely on where the decorations get loaded. Right. > I wonder if it would help to move the ability to handle decoration > filter down from the log layer to revisions.c API layer. >

Re: Simplify-by-decoration with decorate-refs-exclude

Am 02.08.19 um 23:20 schrieb Junio C Hamano: > René Scharfe writes: > >> Having cmd_log_init_finish() call load_ref_decorations() before >> setup_revisions() would indeed solve the issue as well. But we need >> to call the latter to check if --pretty=raw was

Re: [PATCH] commit-reach: fix sorting commits by generation

Am 22.10.2018 um 23:10 schrieb Thomas Gummerer: > compare_commit_by_gen is used to sort a list of pointers to 'struct > commit'. The comparison function for qsort is called with pointers to > the objects it needs to compare, so when sorting a list of 'struct > commit *', the arguments are of type

Re: [PATCH] khash: silence -Wunused-function

Am 23.10.2018 um 13:34 schrieb Carlo Marcelo Arenas Belón: > after 36da893114 ("config.mak.dev: enable -Wunused-function", 2018-10-18) > macro generated code should use a similar solution than commit-slab to > silence the compiler. With Clang 6 and GCC 8 on Debian I don't get any warnings on maste

Re: [PATCH 9/9] fetch-pack: drop custom loose object cache

Am 12.11.2018 um 15:55 schrieb Jeff King: > Commit 024aa4696c (fetch-pack.c: use oidset to check existence of loose > object, 2018-03-14) added a cache to avoid calling stat() for a bunch of > loose objects we don't have. > > Now that OBJECT_INFO_QUICK handles this caching itself, we can drop the

Re: [PATCH 7/9] object-store: provide helpers for loose_objects_cache

Am 12.11.2018 um 15:50 schrieb Jeff King: > --- a/sha1-file.c > +++ b/sha1-file.c > @@ -2125,6 +2125,32 @@ int for_each_loose_object(each_loose_object_fn cb, > void *data, > return 0; > } > > +static int append_loose_object(const struct object_id *oid, const char *path, > +

Re: [PATCH 9/9] fetch-pack: drop custom loose object cache

Am 12.11.2018 um 20:32 schrieb Ævar Arnfjörð Bjarmason: > > On Mon, Nov 12 2018, René Scharfe wrote: >> This removes the only user of OBJECT_INFO_IGNORE_LOOSE. #leftoverbits > > With this series applied there's still a use of it left in > oid_object_info_extended()

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

Am 13.11.2018 um 11:02 schrieb Ævar Arnfjörð Bjarmason: > So here's the same test not against NFS, but the local ext4 fs (CO7; > Linux 3.10) for sha1collisiondetection.git: > > Test origin/master > peff/jk/loose-cacheavar/check-collision

Re: [PATCH/RFC v1 1/1] Use size_t instead of unsigned long

Am 19.11.2018 um 06:33 schrieb Torsten Bögershausen: > The archive-tar.c is actually a good example, why a step-by-step update > is not ideal (the code would not work any more on Win64). > > If we look here: > > static int stream_blocked(const struct object_id *oid) > { > struct git_istream

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

Am 12.11.2018 um 15:54 schrieb Jeff King: > diff --git a/sha1-file.c b/sha1-file.c > index 4aae716a37..e53da0b701 100644 > --- a/sha1-file.c > +++ b/sha1-file.c > @@ -921,6 +921,24 @@ static int open_sha1_file(struct repository *r, > return -1; > } > > +static int quick_has_loose(struct re

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

Am 13.11.2018 um 11:02 schrieb Ævar Arnfjörð Bjarmason: > > On Mon, Nov 12 2018, Ævar Arnfjörð Bjarmason wrote: > >> On Mon, Nov 12 2018, Ævar Arnfjörð Bjarmason wrote: >> >>> I get: >>> >>> Test origin/master >>> peff/jk/loose-cache avar/

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

Am 03.12.2018 um 23:04 schrieb Jeff King: > On Sun, Dec 02, 2018 at 11:52:50AM +0100, René Scharfe wrote: > >>> And for mu.git, a ~20k object repo: >>> >>> Test origin/master >>> peff/jk/loos

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

Am 05.12.2018 um 05:46 schrieb Jeff King: > On Tue, Dec 04, 2018 at 10:45:13PM +0100, René Scharfe wrote: > >>> The comment in the context there is warning callers to remember to load >>> the cache first. Now that we have individual caches, might it make sense >>&

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

Am 05.12.2018 um 09:15 schrieb Jeff King: > On Wed, Dec 05, 2018 at 01:51:36AM -0500, Jeff King wrote: > >>> This >>> function is easily converted to struct object_id, though, as its single >>> caller can pass one on -- this makes the copy unnecessary. >> >> If you mean modifying sha1_loose_object

Re: [PATCH 15/16] commit-reach: make can_all_from_reach... linear

Am 28.06.2018 um 14:31 schrieb Derrick Stolee via GitGitGadget: > diff --git a/commit-reach.c b/commit-reach.c > index c58e50fbb..ac132c8e4 100644 > --- a/commit-reach.c > +++ b/commit-reach.c > @@ -513,65 +513,88 @@ int commit_contains(struct ref_filter *filter, struct > commit *commit, > r

Re: [PATCH] grep: provide a noop --recursive option

Am 29.09.2018 um 19:11 schrieb Junio C Hamano: > I however do not mind if we added "--recursive" with matching > "--no-recursive", and > > - made "--recursive" the default (obviously) > > - made "--no-recursive" a synonym to setting the recursion limit >to "never recurse" > > - and made "

Re: [PATCH 2/2] fsck: use oidset for skiplist

Am 28.08.2018 um 01:03 schrieb Jeff King: > On Sun, Aug 26, 2018 at 01:37:41PM +0200, René Scharfe wrote: >> So it seems worth it. > > Hmm, that really does. Which is a shame, because I hoped that one day we > could get rid of the nasty macro-infestation that is khash.h. But it

Re: What's cooking in git.git (Sep 2018, #04; Thu, 20)

Am 21.09.2018 um 07:22 schrieb Junio C Hamano: > * cc/delta-islands (2018-08-16) 7 commits > (merged to 'next' on 2018-08-27 at cf3d7bd93f) > + pack-objects: move 'layer' into 'struct packing_data' > + pack-objects: move tree_depth into 'struct packing_data' > + t5320: tests for delta islands

Re: [PATCH 15/16] commit-reach: make can_all_from_reach... linear

Am 01.10.2018 um 21:26 schrieb Derrick Stolee: > On 10/1/2018 3:16 PM, René Scharfe wrote: >> Am 28.06.2018 um 14:31 schrieb Derrick Stolee via GitGitGadget: >>> diff --git a/commit-reach.c b/commit-reach.c >>> index c58e50fbb..ac132c8e4 100644 >>> --- a/com

Re: What's cooking in git.git (Sep 2018, #04; Thu, 20)

Am 01.10.2018 um 22:12 schrieb Jeff King: > On Mon, Oct 01, 2018 at 09:16:07PM +0200, René Scharfe wrote: > >> Am 21.09.2018 um 07:22 schrieb Junio C Hamano: >>> * cc/delta-islands (2018-08-16) 7 commits >> [...] >>> * jk/pack-delta-reuse-with-bitmap (2018-08-

Re: [PATCH 2/2] fsck: use oidset for skiplist

Am 01.10.2018 um 22:26 schrieb Jeff King: > On Mon, Oct 01, 2018 at 09:15:53PM +0200, René Scharfe wrote: > The reason hashmap.c was added was to avoid open addressing. ;) Because efficient removal of elements is easier to implement with chaining, according to 6a364ced49 (add a has

[PATCH] sequencer: use return value of oidset_insert()

oidset_insert() returns 1 if the object ID is already in the set and doesn't add it again, or 0 if it hadn't been present. Make use of that fact instead of checking with an extra oidset_contains() call. Signed-off-by: Rene Scharfe --- sequencer.c | 4 +--- 1 file changed, 1 insertion(+), 3 dele

[PATCH v2 0/2] oidset: use khash

Continue the discussion of speeding up oidset started in [1] here in its own thread. [1] https://public-inbox.org/git/20180811172350.ga2...@sigill.intra.peff.net/ The first patch does a mild refactoring to support khash structures on the stack, and the second one converts oidset to khash. khas

[PATCH v2 1/2] khash: factor out kh_release_*

Add a function for releasing the khash-internal allocations, but not the khash structure itself. It can be used with on-stack khash structs. Signed-off-by: Rene Scharfe --- 1 tab = 4 spaces here. khash.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/khash.h b/kha

[PATCH v2 2/2] oidset: use khash

Reimplement oidset using khash.h in order to reduce its memory footprint and make it faster. Performance of a command that mainly checks for duplicate objects using an oidset, with master and Clang 6.0.1: $ cmd="./git-cat-file --batch-all-objects --unordered --buffer --batch-check='%(objectnam

Re: [PATCH v2 2/2] oidset: use khash

Am 03.10.2018 um 21:40 schrieb Jeff King: > On Wed, Oct 03, 2018 at 03:16:39PM +0200, René Scharfe wrote: >> diff --git a/fetch-pack.c b/fetch-pack.c >> index 75047a4b2a..a839315726 100644 >> --- a/fetch-pack.c >> +++ b/fetch-pack.c >> @@ -536,7 +536,7 @@ static i

Re: [PATCH v2 2/2] oidset: use khash

Am 04.10.2018 um 08:48 schrieb Jeff King: > On Thu, Oct 04, 2018 at 07:56:44AM +0200, René Scharfe wrote: > >>> As the comment above notes, I think we're really looking at the case >>> where this gets populated on the first call, but not subsequent ones. It >

[PATCH v3 0/5] oidset: use khash

Two new patches to avoid using oidset internals in fetch-pack: fetch-pack: factor out is_unmatched_ref() fetch-pack: load tip_oids eagerly iff needed Unchanged patch: khash: factor out kh_release_* Unchanged, except it doesn't touch fetch-pack anymore: oidset: use khash A new patch, t

[PATCH v3 1/5] fetch-pack: factor out is_unmatched_ref()

Move the code to determine if a request is unmatched to its own little helper. This allows us to reuse it in a subsequent patch. Signed-off-by: Rene Scharfe --- fetch-pack.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/fetch-pack.c b/fetch-pack.c inde

[PATCH v3 2/5] fetch-pack: load tip_oids eagerly iff needed

tip_oids_contain() lazily loads refs into an oidset at its first call. It abuses the internal (sub)member .map.tablesize of that oidset to check if it has done that already. Determine if the oidset needs to be populated upfront and then do that instead. This duplicates a loop, but simplifies the

[PATCH v3 3/5] khash: factor out kh_release_*

Add a function for releasing the khash-internal allocations, but not the khash structure itself. It can be used with on-stack khash structs. Signed-off-by: Rene Scharfe --- 1 tab = 4 spaces here. khash.h | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/khash.h b/kha

[PATCH v3 4/5] oidset: use khash

Reimplement oidset using khash.h in order to reduce its memory footprint and make it faster. Performance of a command that mainly checks for duplicate objects using an oidset, with master and Clang 6.0.1: $ cmd="./git-cat-file --batch-all-objects --unordered --buffer --batch-check='%(objectnam

[PATCH 5/5] oidset: uninline oidset_init()

There is no need to inline oidset_init(), as it's typically only called twice in the lifetime of an oidset (once at the beginning and at the end by oidset_clear()) and kh_resize_* is quite big, so move its definition to oidset.c. Document it while we're at it. Signed-off-by: Rene Scharfe --- oi

Re: [PATCH v3 2/5] fetch-pack: load tip_oids eagerly iff needed

Am 04.10.2018 um 23:38 schrieb Jonathan Tan: >> Determine if the oidset needs to be populated upfront and then do that >> instead. This duplicates a loop, but simplifies the existing one by >> separating concerns between the two. > > [snip] > >> +if (strict) { >> +for (i = 0; i <

Re: [PATCH 15/16] commit-reach: make can_all_from_reach... linear

Am 01.10.2018 um 22:37 schrieb René Scharfe: > Am 01.10.2018 um 21:26 schrieb Derrick Stolee: >> On 10/1/2018 3:16 PM, René Scharfe wrote: >>> Am 28.06.2018 um 14:31 schrieb Derrick Stolee via GitGitGadget: >>>> diff --git a/commit-reach.c b/commit-reach.c >>

Re: [PATCH 15/16] commit-reach: make can_all_from_reach... linear

Am 05.10.2018 um 18:51 schrieb Jeff King: > On Fri, Oct 05, 2018 at 12:59:02AM +0200, René Scharfe wrote: > >> We could also do something like this to reduce the amount of manual >> casting, but do we want to? (Macro at the bottom, three semi-random >> examples at th

Re: [PATCH 15/16] commit-reach: make can_all_from_reach... linear

Am 05.10.2018 um 21:08 schrieb Jeff King: > On Fri, Oct 05, 2018 at 08:48:27PM +0200, René Scharfe wrote: >> +#define DEFINE_SORT(name, type, compare)\ >> +static int compare##_void(const void *one,

Re: [PATCH v3 2/5] fetch-pack: load tip_oids eagerly iff needed

Am 05.10.2018 um 00:11 schrieb René Scharfe: > Am 04.10.2018 um 23:38 schrieb Jonathan Tan: >> I don't think the concerns are truly separated - the first loop quoted >> needs to know that in the second loop, tip_oids is accessed only if >> there is at least one unmatche

Re: [PATCH v3 2/5] fetch-pack: load tip_oids eagerly iff needed

Am 05.10.2018 um 00:07 schrieb Jeff King: > On Thu, Oct 04, 2018 at 05:09:39PM +0200, René Scharfe wrote: > >> tip_oids_contain() lazily loads refs into an oidset at its first call. >> It abuses the internal (sub)member .map.tablesize of that oidset to >> check if

Re: [PATCH v3 2/5] fetch-pack: load tip_oids eagerly iff needed

Am 05.10.2018 um 22:27 schrieb Jeff King: > On Fri, Oct 05, 2018 at 10:13:34PM +0200, René Scharfe wrote: > >>>> -{ >>>> - /* >>>> - * Note that this only looks at the ref lists the first time it's >>>> - * called. This works out in

Re: [PATCH v3] coccicheck: process every source file at once

Am 05.10.2018 um 21:00 schrieb Jeff King: > On Fri, Oct 05, 2018 at 08:50:50PM +0200, SZEDER Gábor wrote: > >> On Fri, Oct 05, 2018 at 12:59:01PM -0400, Jeff King wrote: >>> On Fri, Oct 05, 2018 at 04:53:35PM +, Keller, Jacob E wrote: >>> > Are we OK with saying 1.3-1.8GB is necessary to r

Re: [PATCH 15/16] commit-reach: make can_all_from_reach... linear

Am 05.10.2018 um 21:42 schrieb Jeff King: > On Fri, Oct 05, 2018 at 09:36:28PM +0200, René Scharfe wrote: > >> Am 05.10.2018 um 21:08 schrieb Jeff King: >>> On Fri, Oct 05, 2018 at 08:48:27PM +0200, René Scharfe wrote: >>>> +#defin

Re: [PATCH 15/16] commit-reach: make can_all_from_reach... linear

Am 15.10.2018 um 17:31 schrieb Derrick Stolee: > On 10/14/2018 10:29 AM, René Scharfe wrote: >> diff --git a/git-compat-util.h b/git-compat-util.h >> index 5f2e90932f..491230fc57 100644 >> --- a/git-compat-util.h >> +++ b/git-compat-util.h >> @@ -1066,6 +1066,21

Re: [PATCH v8 1/2] json_writer: new routines to create data in JSON format

le encode such strings) in the future. > > The initial use for the json-writer routines is for generating telemetry > data for executed Git commands. Later, we may want to use them in other > commands, such as status. > > Helped-by: René Scharfe > Helped-by:

Re: [PATCH v8 1/2] json_writer: new routines to create data in JSON format

Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com: > From: Jeff Hostetler > +/* > + * Add comma if we have already seen a member at this level. > + */ > +static inline void maybe_add_comma(struct json_writer *jw) > +{ > + if (!jw->open_stack.len) > + return; This is impossible

Re: [PATCH v8 1/2] json_writer: new routines to create data in JSON format

Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com: > Makefile| 2 + > json-writer.c | 419 > json-writer.h | 113 + > t/helper/test-json-writer.c | 572 >

Re: [PATCH 2/2] builtin/blame: highlight recently changed lines

Am 17.04.2018 um 23:30 schrieb Stefan Beller: > +static void parse_color_fields(const char *s) > +{ > + struct string_list l = STRING_LIST_INIT_DUP; > + struct string_list_item *item; > + enum { EXPECT_DATE, EXPECT_COLOR } next = EXPECT_COLOR; > + > + colorfield_nr = 0; > + > +

Re: [PATCH 24/30] merge-recursive: Add computation of collisions due to dir rename & merging

Am 10.11.2017 um 20:05 schrieb Elijah Newren: > +static struct dir_rename_entry *check_dir_renamed(const char *path, > + struct hashmap *dir_renames) { > + char temp[PATH_MAX]; > + char *end; > + struct dir_rename_entry *entry; > + > + s

Re: [PATCH 24/30] merge-recursive: Add computation of collisions due to dir rename & merging

Am 10.06.2018 um 12:56 schrieb René Scharfe: > Am 10.11.2017 um 20:05 schrieb Elijah Newren: >> +static struct dir_rename_entry *check_dir_renamed(const char *path, >> + struct hashmap *dir_renames) { >> +char temp[PATH_MA

Re: [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'

Am 19.06.2018 um 18:35 schrieb Jeff King: > On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote: >> The notable case that it does _not_ cover is matching the following >> line: >> >>a ... b >> >> with the following expression >> >>git grep --column -e b --or -e a >> >> This will pro

Re: [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'

Am 19.06.2018 um 19:44 schrieb Taylor Blau: > On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote: >> Am 19.06.2018 um 18:35 schrieb Jeff King: >>> On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote: >> We could add an optimizer pass to reduce the number o

Re: [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'

Am 19.06.2018 um 19:48 schrieb Jeff King: > On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote: > >>> The key thing about this iteration is that it doesn't regress >>> performance, because we always short-circuit where we used to. The other >>> obv

Re: [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'

Am 19.06.2018 um 19:44 schrieb Taylor Blau: > diff --git a/grep.c b/grep.c > index f3329d82ed..a09935d8c5 100644 > --- a/grep.c > +++ b/grep.c > @@ -1257,8 +1257,8 @@ static int match_one_pattern(struct grep_pat *p, char > *bol, char *eol, > return hit; > } > > -static int match_expr_eval

Re: [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'

Am 19.06.2018 um 21:11 schrieb Jeff King: > On Tue, Jun 19, 2018 at 08:50:16PM +0200, René Scharfe wrote: > >> Negation causes the whole non-matching line to match, with --column >> reporting 1 or nothing in such a case, right? Or I think doing the >> same when the oper

Re: [PATCH 24/31] archive-tar: make hash size independent

Am 12.02.2019 um 02:22 schrieb brian m. carlson: > diff --git a/builtin/get-tar-commit-id.c b/builtin/get-tar-commit-id.c > index 2706fcfaf2..2760549e91 100644 > --- a/builtin/get-tar-commit-id.c > +++ b/builtin/get-tar-commit-id.c > @@ -5,6 +5,7 @@ > #include "commit.h" > #include "tar.h" > #in

Re: [PATCH 24/31] archive-tar: make hash size independent

Am 12.02.2019 um 08:20 schrieb René Scharfe: > That command currently prints the pax comment in tar archives if it > looks like a SHA1 hash based on its length. It should continue to do > so, and _also_ show longer hashes. Your change makes it _only_ show > those longer hashes. >

Re: [PATCH 0/5] Misc Coccinelle-related improvements

Am 23.07.2018 um 15:50 schrieb SZEDER Gábor: > Just a couple of minor Coccinelle-related improvements: > >- The first two patches are small cleanups. > >- The last three could make life perhaps just a tad bit easier for > devs running 'make coccicheck'. > > > SZEDER Gábor (5): >

Re: Proposed approaches to supporting HTTP remotes in "git archive"

Am 28.07.2018 um 00:32 schrieb Junio C Hamano: > Josh Steadmon writes: > >> # Supporting HTTP remotes in "git archive" >> >> We would like to allow remote archiving from HTTP servers. There are a >> few possible implementations to be discussed: >> >> ## Shallow clone to temporary repo >> >> This

Re: git merge -s subtree seems to be broken.

Am 31.07.2018 um 17:50 schrieb Jeff King: > On Tue, Jul 31, 2018 at 11:03:17AM -0400, George Shammas wrote: > >> Bisecting around, this might be the commit that introduced the breakage. >> >> https://github.com/git/git/commit/d8febde >> >> I really hope that it hasn't been broken for 5 years and I

Re: git merge -s subtree seems to be broken.

Am 31.07.2018 um 23:06 schrieb Junio C Hamano: > Jeff King writes: > >> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote: >> ... >> So here it is fixed, and with a commit message. I'm not happy to omit a >> regression test, but I actually couldn't come up with a minimal one that >> tickl

[PATCH] remote: clear string_list after use in mv()

Switch to the _DUP variant of string_list for remote_branches to allow string_list_clear() to release the allocated memory at the end, and actually call that function. Free the util pointer as well; it is allocated in read_remote_branches(). NB: This string_list is empty until read_remote_branche

Re: [PATCH] remote: clear string_list after use in mv()

Thank you for the review! Am 02.08.2018 um 04:56 schrieb Jonathan Nieder: > René Scharfe wrote: > >> Subject: remote: clear string_list after use in mv() > > This subject line doesn't fully reflect the goodness of this change. > How about something like: > >

Re: [PATCH] push: comment on a funny unbalanced option help

Am 02.08.2018 um 00:31 schrieb Ævar Arnfjörð Bjarmason: > But looking at this again it looks like this whole thing should just be > replaced by: > > diff --git a/builtin/push.c b/builtin/push.c > index 9cd8e8cd56..b8fa15c101 100644 > --- a/builtin/push.c > +++ b/builtin/push.c

Re: [PoC] coccinelle: make Coccinelle-related make targets more fine-grained

Am 02.08.2018 um 13:55 schrieb SZEDER Gábor: > Let's add a bit of Makefile metaprogramming to generate finer-grained > make targets applying one semantic patch to only a single source file, > and specify these as dependencies of the targets applying one semantic > patch to all source files. This w

Re: [PATCH] push: comment on a funny unbalanced option help

Am 02.08.2018 um 16:21 schrieb Ævar Arnfjörð Bjarmason: > > On Thu, Aug 02 2018, René Scharfe wrote: > >> Am 02.08.2018 um 00:31 schrieb Ævar Arnfjörð Bjarmason: >>> But looking at this again it looks like this whole thing should just be >>> replaced by: >>

Re: [PATCH] push: comment on a funny unbalanced option help

Am 02.08.2018 um 17:06 schrieb René Scharfe: > According to its manpage the option should rather be shown like this: > > --force-with-lease[=[:]] > > ... to indicate that all three forms are valid: > > --force-with-lease > --force-with-lease=some_ref &g

Re: Re* [PATCH] push: comment on a funny unbalanced option help

> the end result would balance out, by somebody who forgot the > presence of PARSE_OPT_LITERAL_ARGHELP, which is the escape hatch > mechanism designed to help such a case. We just should use the > official escape hatch instead. > > Helped-by: René Scharfe I didn't do anyt

Re: [PATCH] push: comment on a funny unbalanced option help

Am 02.08.2018 um 17:31 schrieb Junio C Hamano: > René Scharfe writes: >> diff --git a/parse-options.c b/parse-options.c >> index 7db84227ab..fadfc6a833 100644 >> --- a/parse-options.c >> +++ b/parse-options.c >> @@ -660,7 +660,8 @@ int parse_options(int argc,

Re: [PATCH] push: comment on a funny unbalanced option help

Am 02.08.2018 um 18:54 schrieb Jeff King: > PS I actually would have made the rule simply "does it begin with a > '<'", which seems simpler still. If people accidentally write " forgetting to close their brackets, that is a bug under both the > old and new behavior (just with slightly d

<    1   2   3   4   5   6   7   8   9   10   >