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
Don't translate the argument specification for --chmod; "+x" and "-x"
are the literal strings that the commands accept.
Separate alternatives using a pipe character instead of a slash, for
consistency.
Use the flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt from adding a
pair of angular bracke
Wrap both placeholders in the argument help string in angular brackets
to signal that users needs replace them with some actual value. Use the
flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt from adding another
pair.
Signed-off-by: Rene Scharfe
---
builtin/pack-objects.c | 4 ++--
1 file cha
Parseopt wraps arguments in a pair of angular brackets by default,
signifying that the user needs to replace it with a value of the
documented type. Remove the pairs from the option definitions to
duplication and confusion.
Signed-off-by: Rene Scharfe
---
builtin/difftool.c | 4 ++--
1 file cha
Wrap each part of the argument help string in angular brackets to show
that users need to replace them with actual values. Do that explicitly
to balance the pairs nicely in the code and avoid confusing casual
readers. Add the flag PARSE_OPT_LITERAL_ARGHELP to keep parseopt from
adding another pai
Parseopt wraps argument help strings in a pair of angular brackets by
default, to tell users that they need to replace it with an actual
value. This is useful in most cases, because most option arguments
are indeed single values of a certain type. The option
PARSE_OPT_LITERAL_ARGHELP needs to be
Wrap the placeholders in the option help string for -w in pairs of
angular brackets to document that users need to replace them with actual
numbers. Use the flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt
from adding another pair.
Signed-off-by: Rene Scharfe
---
builtin/shortlog.c | 6 --
Am 02.08.2018 um 22:01 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> 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
Am 02.08.2018 um 22:36 schrieb Junio C Hamano:
> Ævar Arnfjörð Bjarmason writes:
>
>> Thanks, FWIW that's fine by me, and also if you want to drop this "fake"
>> patch of mine and replace it with something René came up with (I have
>> not yet read his 1-6 patches submitted on this topic, so maybe
The char array named "buffer" is unlikely to contain a NUL character, so
printing its contents using %s in a die() format is unsafe. Clang's
ASan reports running over the end of buffer in the recently added
skiplist tests in t5504-fetch-receive-strict.sh as a result.
Use an idiomatic strbuf_getl
Object IDs to skip are stored in a shared static oid_array. Lookups do
a binary search on the sorted array. The code checks if the object IDs
are already in the correct order while loading and skips sorting in that
case.
Simplify the code by using an oidset instead. Memory usage is a bit
highe
Am 11.08.2018 um 19:23 schrieb Jeff King:
On Sat, Aug 11, 2018 at 01:02:48PM -0400, Jeff King wrote:
- we could probably improve the speed of oidset. Two things I notice
about its implementation:
Before any optimizations, my best-of-five timing for:
git cat-file --batch-all-objec
Am 11.08.2018 um 18:48 schrieb Jeff King:
And one I'm not sure about:
- a read() error will now be quietly ignored; I guess we'd have to
check ferror(fp) to cover this. I'm not sure if it matters.
I'm not sure, either. It would catch media errors or file system
corruption, right? Sound
Am 11.08.2018 um 19:23 schrieb Jeff King:
On Sat, Aug 11, 2018 at 01:02:48PM -0400, Jeff King wrote:
- we could probably improve the speed of oidset. Two things I notice
about its implementation:
- it has to malloc for each entry, which I suspect is the main
bottleneck.
Am 11.08.2018 um 22:59 schrieb René Scharfe:
If the current oidset implementation is so bad, why not replace it with
one based on oid_array? ;-)
Intuitively I'd try a hashmap with no payload and open addressing via
sha1hash(), which should reduce memory allocations quite a bit -- no
ne
Am 13.08.2018 um 20:43 schrieb Junio C Hamano:
René Scharfe writes:
@@ -182,19 +181,10 @@ static int fsck_msg_type(enum fsck_msg_id msg_id,
static void init_skiplist(struct fsck_options *options, const char
*path)
{
- static struct oid_array skiplist = OID_ARRAY_INIT;
- int
Am 13.08.2018 um 23:07 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> the mailing list [1], nor on the web interface [2]. The latter shows
>> extra spaces on the context lines of the first hunk, though, which I
>> can't see anywhere else. All the lines
> on, which in turn makes it easy to see where we need to be
> releasing the string in the caller (right after the loop
> which uses it in each case).
>
> Based-on-a-patch-by: René Scharfe
> Signed-off-by: Jeff King
> ---
> It also made it easy to see that without the prio
Spell out all alternatives and avoid using a numerical range operator,
as it is not mentioned in CodingGuidelines and the resulting string is
still concise. Wrap them in parentheses to document clearly that the
"--stage=" part is common among them.
Signed-off-by: Rene Scharfe
---
builtin/checko
This formally clarifies that the "--option=" part is the same for all
alternatives.
Signed-off-by: Rene Scharfe
---
builtin/pull.c | 2 +-
builtin/push.c | 4 ++--
builtin/send-pack.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/pull.c b/builtin/pull.c
Group the possible values using a pair of parentheses and don't mark
them for translation, as they are literal strings that have to be used
as-is in any locale.
Signed-off-by: Rene Scharfe
---
builtin/remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b
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
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
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
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,
> +
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()
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
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
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
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/
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
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
>>&
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
Am 11.08.2018 um 22:48 schrieb Ramsay Jones:
> On 11/08/18 16:47, René Scharfe wrote:
>> @@ -34,12 +36,12 @@ struct fsck_options {
>> fsck_error error_func;
>> unsigned strict:1;
>> int *msg_type;
>> - struct oid_array *skiplist;
>> +
Am 11.08.2018 um 18:54 schrieb Ævar Arnfjörð Bjarmason:
>
> On Sat, Aug 11 2018, René Scharfe wrote:
>
>> Object IDs to skip are stored in a shared static oid_array. Lookups do
>> a binary search on the sorted array. The code checks if the object IDs
>> are already
Object IDs to skip are stored in a shared static oid_array. Lookups do
a binary search on the sorted array. The code checks if the object IDs
are already in the correct order while loading and skips sorting in that
case. Lookups are done before reporting a (non-fatal) corruption and
before check
buffer is unlikely to contain a NUL character, so printing its contents
using %s in a die() format is unsafe (detected with ASan).
Use an idiomatic strbuf_getline() loop instead, which ensures the buffer
is always NUL-terminated, supports CRLF files as well, accepts files
without a newline after t
Add best-effort support for patches sent using format=flowed (RFC 3676).
Remove leading spaces ("unstuff"), remove soft line breaks (indicated
by space + newline), but leave the signature separator (dash dash space
newline) alone.
Warn in git am when encountering a format=flowed patch, because any
Am 14.08.2018 um 03:58 schrieb Jeff King:
> Your suggestion can be implemented using khash (my patch below).
>
>> Before:
>> Benchmark #1: ./git-cat-file --batch-all-objects --buffer --unordered
>> --batch-check='%(objectname)'
>>
>> Time (mean ± σ): 269.5 ms ± 26.7 ms[User: 247.7 ms,
Am 27.08.2018 um 09:37 schrieb Ævar Arnfjörð Bjarmason:
>
> On Sat, Aug 25 2018, René Scharfe wrote:
>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index 2fa65b7516..80ab570579 100644
>> --- a/Documentation/config.txt
>> +++ b/Docum
Am 27.08.2018 um 22:15 schrieb Ævar Arnfjörð Bjarmason:
>
> On Mon, Aug 27 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> From: René Scharfe
>>
>> Object IDs to skip are stored in a shared static oid_array. Lookups do
>> a binary search on the sorted array. The cod
Am 28.08.2018 um 11:52 schrieb Ævar Arnfjörð Bjarmason:
> It's annoying not to be able to put comments and empty lines in the
> skipList, when e.g. keeping a big central list of commits to skip in
> /etc/gitconfig, which was my motivation for 1362df0d41 ("fetch:
> implement fetch.fsck.*", 2018-07-2
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
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 "
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
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
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
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-
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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 <
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
>>
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
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,
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
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
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
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
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
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
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
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.
>
Am 05.04.2019 um 01:25 schrieb Jeff King:
> When we have a .midx that covers many packfiles, we try to avoid opening
> the .idx for those packfiles. However, there are a few problems with the
> filename comparison we use:
>
>- we ask midx_contains_pack() about the .pack name, not the .idx name.
Am 05.04.2019 um 01:27 schrieb Jeff King:
> We can use skip_prefix() and parse_oid_hex() to continuously increment
> our pointer, rather than dealing with magic numbers. This also fixes a
> few small shortcomings:
>
> - if we see a 'P' line that does not match our expectations, we'll
> leave
Am 05.04.2019 um 20:11 schrieb Jeff King:
> On Fri, Apr 05, 2019 at 12:41:27PM +0200, René Scharfe wrote:
>> Parsing "P" and "pack-" together crosses logical token boundaries,
>> but that I don't mind it here.
>
> Yeah, I was tempted to
s does fix _a_ bug, it's masked
> by another bug in that same caller. That will be covered (with a test)
> in the next patch.
>
> Helped-by: René Scharfe
> Signed-off-by: Jeff King
> ---
> I was tempted to suggest that the midx struct just store the base name
> withou
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>
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
Am 06.08.19 um 18:36 schrieb Carlo Marcelo Arenas Belón:
> 94da9193a6 (grep: add support for PCRE v2, 2017-06-01) didn't include
> a way to override the system allocator, and so it is incompatible with
> USE_NED_ALLOCATOR. The problem was made visible when an attempt to
> avoid a leak in a data st
Signed-off-by: René Scharfe
---
Patch generated with --function-context for easier review. That makes
it look a lot bigger than it actually is, though.
The plugged leaks were added after v2.22.0 (2019-06-07) by the following
commits:
5c84b3396c 2019-06-18 commit-graph: load commit-graph chains
Avoid allocating and leaking a strbuf for holding a verbatim copy of the
path argument and pass the latter directly to dir_iterator_begin()
instead.
Signed-off-by: René Scharfe
---
This test helper was added after v2.22.0 (2019-06-07) by 150791adbf
(dir-iterator: add tests for dir-iterator API
Signed-off-by: René Scharfe
---
Patch generated with --function-context for easier review.
The plugged leak was added after v2.22.0 (2019-06-07) by 3012397e03
(dir-iterator: refactor state machine model, 2019-07-10).
refs/files-backend.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
1101 - 1200 of 1338 matches
Mail list logo
